[sc34wg3] Removing added scope from <mergeMap>

[Steve Pepper]

* 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

--
Steve Pepper <pepper@ontopia.net>
Chief Strategy Officer, Ontopia
Convenor, ISO/IEC JTC 1/SC 34/WG 3
Editor, XTM (XML Topic Maps 1.0)