[sc34wg3] XTM 1.1 issues
Lars Marius Garshol
Wed, 14 Dec 2005 15:16:34 +0100
* Robert Barta
> I support this view, namely that of XTM being an _interchange_ syntax,
> not an authoring syntax. This is a shift of focus away from the
> 2000iesh understanding, though, which some members will be reluctant
> to follow.
Well, it was there in the requirements, right at the top of the XTM
1.0 document, even if it wasn't really followed. :)
> Me too, although the separate <value> element is not overly lean.
We can't just dump the value into the content of the topicName
element, as this causes difficulties with roundtripping of
whitespace, etc. So I can't really see a way to do without <value>,
regardless of what we call it. (Kal already suggested reusing
<resourceData> instead, but that has a datatype attribute, so that's
* Lars Marius Garshol
> This change, however, makes it difficult to write the XSLT translation
> stylesheet, though that's not really a valid argument against it. The
> translation is still very much possible, it just becomes hard to do in
* Robert Barta
> I thought it would get easier: fewer elements, one canonical place to
> find things...
This was referring specifically to the XSLT stylesheet for converting
XTM 1.0 documents to XTM 1.1 that the committee said we have to
include in the spec. I think I can see a way to do it, though, so we
should be OK.
> Hmmm, should item identifiers really be serialized? Is this role not
> completely covered with IDs on topics and the "reifier" attribute
It's not strictly speaking needed, but without it
(1) Not all aspects of the model can be interchanged, and
(2) It is impossible to use XTM 1.1 to support distributed editing
scenarios by passing fragments between client and server.
Whether the latter falls under the interchange heading could be
discussed at length, but what decided the editors was that without it
this can't be done at all within standard XTM 1.1.
> I have critized <mergeMap> for many years exactly for the reasons you
> write, especially for interchange. Even for authoring, I am EXTREMELY
> reluctant to have such a "include" feature. It is NOT the right horse
> for the right course.
I agree. An alternative (proposed by Kal) would be to create an extra
Topic Map Packaging syntax that can be used to define modules by
having references to the files to read in. We decided not to do this
as adding one more syntax this late in the process is not really a
good idea. It would also mean that the modules would not be self-
contained, in the sense that they would not declare themselves what
So I think the reality is that <mergeMap> will stay with us for a while.
> - topicRefs only point to topics and are IDREF
> - and consequently EVERYTHING can be interpreted 'relative' (inside
> the document),
> then you might be able to remove it. But this has to be thought
Well, we can have topicRef point using IRIs without supporting
xml:base. Everything should work just as well without xml:base, I
would think. You just use normal relative IRIs, and make sure that
you distribute all the files.
> There are no badCamels and no GoodCamels (only the camel on the Perl
> book is a good camel) :-)
I agree there are no good camels. :)
> PS: Your cleanup efforts are MUCH appreciated.
Thanks for the comments. It really helps to get this kind of feedback.
Lars Marius Garshol, Ontopian http://www.ontopia.net
+47 98 21 55 50 http://