[sc34wg3] XTM 1.1 issues

[Lars Heuer]

Hi Murray,

[...]
>> 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. :)

Best regards,
Lars
-- 
http://semagia.com