[sc34wg3] XTM 1.1 issues
Fri, 16 Dec 2005 13:14:19 +0100
>> Anyway, I think it is a failure to keep the mergeMap element in the
>> XTM 1.1. This might belong to the upcoming CTM syntax which is
>> designed for _authoring_ topic maps, while XTM should be designed for
>> _interchanging_ topic maps (XTM should be readable by humans, though).
> Perhaps you have a limited view of interchange. I think of being
> able to interchange either an entire vocabulary, or, when we talk
> about modularization, a subset of a vocabulary. When looking at
Jep, I'd call my view a "different" view, not a "limited", but okay.
IMO the supplier of the topic map can extract a fragment from it (i.e.
using TMQL or tolog) and send it to the client. Or the client extracts
the fragments of interest by herself.
> precisely the functionality necessary. At an application level, it
> permits either a human or program to decide whether or not to
> traverse the link bringing in the module. "Interchange" in this
At application level the human or program decides to merge the topic
map X with the topic map Y as \rho and LMG has pointed out. She can
decide the merging of topic maps without a mergeMap element.
> XTM is readable by humans, but nobody except geeks should ever have
> to look at XTM or XML markup.
I agree with you here.
> XTM is not PDF.
Good point ;)
Anyway, it seems that the mergeMap element will stay, but I am not
very happy with it.
Summary: Murray is unhappy with XTM 1.1, Lars is happy with XTM 1.1
but not with the mergeMap element. :)