[sc34wg3] XTM 1.1 issues

Murray Altheim sc34wg3@isotopicmaps.org
Fri, 16 Dec 2005 16:49:16 +0000

Lars Heuer wrote:
> 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.
> :)

Well, you defined a version of "interchange" that didn't include the
use case I had provided, so by definition your view is more limited
than mine. That's all I meant.

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

This is a more complicated scenario than I either imagined or was
providing as my use case, which is merely the distribution of one
or more LTM or XTM files over the Web.

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

Yes, in that scenario the mergeMap element is not required. In my
scenario it is. My scenario is simpler and therefore more likely
to be used by people. Your scenario is also proposing that merging
of individual Topic Maps happens only within an application, then
the already-merged result is serialized for interchange. My scenario
involves providing a set of Topic Map documents from which a user or
an application can pick and choose as necessary. Yes, my scenario
involves a file metaphor, the predominant one in use worldwide at
this time, and likely for at least the next decade.

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

No, I have not expressed that I am unhappy with XTM 1.1, only that
it is misnamed. I'm sure that given Lars Marius is an excellent
engineer, that it is very likely a very good serialization of the
TMDM model of Topic Maps. It's just not "XTM" anymore.


Murray Altheim                          http://www.altheim.com/murray/
Strategic Services Development Manager
The Open University Library and Learning Resources Centre
The Open University, Milton Keynes, Bucks, MK7 6AA, UK               .

    As late as 1855, New York newspapers reported that Presbyterian,
    Baptist and Methodist churches were closed on Dec. 25 because
    "they do not accept the day as a Holy One." On the eve of the
    Civil War, Christmas was recognized in just 18 states.