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

[Lars Marius Garshol]

* Kal Ahmed
>
> 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.

This is what the 2005-07-20 draft did. That you came up with the same  
principle is encouraging.

The tricky thing (for implementors) is of course that the topics in  
that scope may merge during processing... :-)

> 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.

This is also what the 2005-07-20 draft did. Note that with XTM 1.1  
this is not a problem, since such references would no longer be  
followed out of the topic map.

You get the same results as 2005-07-20 for cases 1-3.

> 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.

I was wrong about this one. The same thing would happen with the  
previous draft; I missed that.@

> [case 4]
>
> 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.

I'm not sure whether 2005-07-20 would give the same result, but this  
sounds like the right result to me.

> 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.

Let's do that if we decide to keep added themes. I'll try to return  
to that subject soon.

--
Lars Marius Garshol, Ontopian               http://www.ontopia.net
+47 98 21 55 50                             http://www.garshol.priv.no