[sc34wg3] How to process <mergeMap> and added scopes?

[Kal Ahmed]

I'm not sure that working specific examples is going to get to the bottom of
this, but if it helps to show that mergeMap *can* be processed consistently
I'll bite on this one.

Processing mergeMap can be made straightforward. During a single instance of
XTM processing (including processing mergeMap directives), the processor
maintains a record of topic maps that have been referenced, and the scope in
which they are referenced. Each mergeMap is recorded as a combination of the
fully-specified URI of the target map and the set of topics that are the
added themes for that mergeMap directive. When a mergeMap directive is
encountered, the topic map should be merged if the target map has not been
merged with the same set of added themes.

The first topic map loaded is recorded as being referenced in the
unconstrained scope. 

You don't have examples of topicRef here - but the processing model can cope
with that. If you have topicRef elements that reference external topic maps,
those are recorded (and processed) as if there were a mergeMap reference to
those external topic maps with the set of added themes currently in force
when the topicRef is encountered.

So applying those rules:
> 
> 1. Does added scope apply to nested <mergeMap>s? Example: what is the
> result of processing document A? How many scoping topics does the base
> name with id="bn" have?
> 
>   A:
>   <topicMap>
>     <mergeMap xlink:href="B"/>
>       <topicRef xlink:href="#theme1"/>
>     </mergeMap>
>   </topicMap>
> 
>   B:
>   <topicMap>
>     <mergeMap xlink:href="C">
>       <topicRef xlink:href="#theme2"/>
>     </mergeMap>
>   </topicMap>
> 
>   C:
>   <topicMap>
>     <topic>
>       <baseName id="bn1"><baseNameString>My
> topic</baseNameString></baseName
>     </topic>
>   </topicMap>
> 

C#bn1 will have two scoping topics. Processing A causes B to be processed
with added theme theme1, which in turn causes C to be processed with added
theme theme2 (I guess implementation wise you would be maintaining a set of
added themes in force at any particular point).

> 2. What happens if nested <mergeMap>s are recursive and added scopes
> are used? Example: what is the result of processing document D?
> 
>   D:
>   <topicMap>
>     <mergeMap xlink:href="E"/>
>       <topicRef xlink:href="#theme2"/>
>     </mergeMap>
>   </topicMap>
> 
>   E:
>   <topicMap>
>     <mergeMap xlink:href="D">
>       <topicRef xlink:href="#theme1"/>
>     </mergeMap>
>   </topicMap>
> 
Processing starts by adding a record that D is referenced in the
unconstrained scope. Processing D adds a record that E is processed with
added theme set {theme2} and causes E to be processed. Processing E adds a
record that D is processed with added theme set {theme2, theme1} and causes
D to be processed. Processing D again adds a record that E is referenced
with added theme set {theme2, theme1} and causes E to be processed.
Processing E for the second time results in a reference to D with added
theme set {theme2, theme1}. That's been done already. Processing stops.

> 3. What happens if multiple <mergeMap>s reference the same document
> with different added scopes? Example: what is the result of processing
> document F?
> 
>   F:
>   <topicMap>
>     <mergeMap xlink:href="G"/>
>       <topicRef xlink:href="#theme1"/>
>     </mergeMap>
>     <mergeMap xlink:href="G"/>
>       <topicRef xlink:href="#theme2"/>
>     </mergeMap>
>   </topicMap>
> 
>   G:
>   <topicMap>
>     <topic>
>       <baseName id="bn2"><baseNameString>My
> topic</baseNameString></baseName
>     </topic>
>   </topicMap>
> 

The first mergeMap directive causes G to be processed with added theme set
{theme1}. The second causes G to be processed with added theme set {theme2}.

> 
> 4. What happens if a <mergeMap>s reference the current document with
> added scopes? Example: what is the result of processing document H?
> 
>   H:
>   <topicMap>
>     <mergeMap xlink:href="H"/>
>     <mergeMap xlink:href="H"/>
>       <topicRef xlink:href="#theme1"/>
>     </mergeMap>
>     <mergeMap xlink:href="H"/>
>       <topicRef xlink:href="#theme2"/>
>     </mergeMap>
>   </topicMap>
> 
H is recorded as being referenced in the unconstrained scope. The first
mergeMap is ignored (as H has already been referenced in the unconstrained
scope). The second mergeMap is recorded as a reference to H with the theme
set {theme1} when H is processed recursively, the first and second mergeMaps
are ignored (as they both reference H with the theme set {theme1}) and the
third mergeMap results in a reference to H with theme set {theme1, theme2}.
After that, no more recursion. Same applies to processing the third mergeMap
in the outer loop.

At first glance it would seem that for this processing to work consistently,
the processing rules would have to specify whether mergeMap directives are
processed depth-first or breadth-first as it may alter topic merging and in
turn alter whether a mergeMap directive is followed. Having said that
someone with a more mathematical brain or more time to figure it out (the
editors? ;-) could probably work out if the order of processing mergeMap
directives really makes any difference at all once all the merging has been
completed - I have a suspicion that it might.

Cheers

Kal