[sc34wg3] XTM 1.1 issues: MergeMap

[Robert Barta]

On Wed, Dec 14, 2005 at 12:15:49AM +0000, Murray Altheim wrote:
> >* Murray Altheim
> >
> >>I don't think of <mergeMap> as authoring, but a component in
> >>modularization.
> >
> >The point is that if you are modularizing in files it must be because  
> >you are authoring in files, at which point it does become an  
> >authoring issue. If you weren't authoring in files, why would you  
> >ever send anyone multiple files? You'd just create a file containing  
> >exactly what you wanted to send (by some suitable form of magic) and  
> >send that.
> 
> Until you or somebody provides me with a functional (and improved)
> alternative to files that everybody else is also using, the file
> metaphor is what I'll be using.

I think the 'file metaphor' is fine, especially for serialized topic
map content, such as one written in LTM or XTM. But it breaks down if
I start to hold my content in a dedicated TM database. I can still
use URIs, though:

   tm:/users/rho/cv/

It also breaks down if I want to wrap a non-topic-map resource with a
TM wrapper (as in my favourite example of a DNS server 'seen' as topic
map):

   dns:localhost/

If I want to 'merge' these two topic maps, where should I put it now?
My reflex is to say "put it as an expression into a query language":

   tm:/users/rho/cv/ + dns:localhost/

And if it works for these, why not for the case of files:

   murray_likes.ltm + jim_likes.xtm

So <mergeMap> is an evolutionary crutch. It will probably stick with
us until proper tool support.

\rho