[sc34wg3] XTM 1.1 issues

[Lars Marius Garshol]

* 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. :)

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

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

* 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
> above?

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

So I think the reality is that <mergeMap> will stay with us for a while.

> [xml:base]
>
> If
>
>   - 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
> through.

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:// 
www.garshol.priv.no