[sc34wg3] Removing added scope from <mergeMap>
Tue, 17 Jan 2006 12:38:10 +0100
I would like to re-add my third option which was to keep mergeMap and added
themes but have two schemas, one base schema with just representation and a
refinement/extension schema that includes the mergeMap element.
From: email@example.com [mailto:firstname.lastname@example.org]
On Behalf Of Steve Pepper
Sent: 17 January 2006 12:17
To: WG3 mail list
Subject: RE: [sc34wg3] Removing added scope from <mergeMap>
* Kal Ahmed
| This is getting circular - I think we have shown the points on both
| side of the debate, so to summarise:
| Added themes on a mergeMap declaration has the advantages of allowing
| you to identify the provenance of individual topic characteristic
| assignments. Its major weakness is in subject identity assignment (and
| resulting merge behaviour). Source locators provide some of the
| functionality of an addedThemes directive but are restricted in that
| (a) they only identify the topic map source and cannot be used to
| identify (for example) the source organization and (b) they would only
| be generated on topic characteristic assignments that have an ID in
| the merged topic map - so you are reliant on the source providing
| those IDs. Furthermore, two users (Murray and Jim) have both said that
they use added themes on a mergeMap.
And (in an earlier posting):
| If the editors feel that there is a strong reason for removing the
| feature, then the onus should be on them to explain it to the
| satisfaction of the community - not the other way round.
I am fairly convinced by the arguments of Kal, Murray, and Jim: I don't
think we should remove added scope unless:
1) we have something better to replace it, or
2) it turns out to be totally broken (not just underpowered).
I am sceptical to Kal and Graham's proposal for Yet Another Language (or
even two) for handling dependencies and merging. If you think you can make a
better case for why these would be a good idea, please do so.
Having said that, I think those in favour of retaining added scope need to
take Geir Ove's posting on "How to process <mergeMap> and added scopes?"
seriously. We don't want to put out a standard where behaviour is left
undefined, so how can we make it watertight?
Steve Pepper <email@example.com>
Chief Strategy Officer, Ontopia
Convenor, ISO/IEC JTC 1/SC 34/WG 3
Editor, XTM (XML Topic Maps 1.0)
sc34wg3 mailing list