[sc34wg3] XLink support in XTM

[Lars Marius Garshol]

* Conal Tuohy
>
> Another comment was that XLink should not be dropped. I want to second
> that.
>
> Although it's perhaps true (as someone mentioned) that it's unlikely
> anyone would want to use a "generic xlink processor" as a platform for
> building a topic map engine, there is more value to using a standard
> linking mechanism than just that. For instance, XML editors and  
> browsers
> are more likely to be "XLink aware" than "XTM aware", and to allow XTM
> authors to navigate those links as a way of exploring and checking  
> their
> XTM instances. I know that Firefox, for instance, is XLink aware,  
> though
> at present there are bugs which obscure this functionality unless your
> XTM instances are styled (with CSS or XSLT), and you have a local copy
> of the XTM DTD.
>
> Maybe XLink hasn't taken the world by storm, but it seems to me that's
> not itself a reason to shun it. I have used XLink in XBRL and SVG,  
> and I
> notice that it has made it into DocBook 5 at last ... so we are hardly
> the only ones. Why not stick with it? It can only get better IMHO.

Your arguments sound very much like the ones I used in September 2000  
to argue that XLink should be used. In all the years that have passed  
since, the total benefit that I can see that it has brought us is  
zero. I don't think the problem is necessarily XLink (I certainly  
have nothing against XLink), but more that any processor that  
understands only XLink but not the rest of the markup isn't really  
going to understand very much of the document, and so anything that  
it provides is not really going to be very useful. You'll always be  
infinitely better off using Topic Maps software than XLink software.

There are also downsides to using XLink in XTM:

  - We don't get value from using a standard linking mechanism, we get
    overhead. It means that implementors must relate to two standards
    (XTM and XLink) instad of just one, and it means that the standards
    editors have to relate to an external standard. This means that we
    have to follow XLink's rules for handling of "#foo" URIs (not clear
    what they are, but when it is clarified it may differ from the  
position
    we take in XTM), for IRIs, and so on.

  - XLink was made for document standards, but XTM documents are not
    documents in the sense that DocBook documents are. You don't really
    want to navigate and traverse the links in the same way, and it's
    unlikely that features offered by XML editors and browsers are  
likely
    to help much. Personally, I find that writing XTM in nxml-mode in
    Emacs would have been much easier if we *hadn't* used XLink (not  
that
    I do this very often).

  - The schemas become quite a bit more complex, as they have to relate
    to two namespaces instead of just one. For XML Schema this means we
    have two have one schema for each namespace.

  - The XLink support forces us to add the xlink:type attribute to all
    XTM elements that have XLinks on them. Without this attribute the
    links will not actually be valid XLinks, but nobody adds this
    attribute. In the DTD you can make it #FIXED, but unless people
    refer to the DTD that won't help, and with some parsers even that
    won't help, and if it does help you're guaranteed that someone
    sooner or later will use that document somewhere where the DTD isn't
    found and trouble ensues.

There's probably more, but the short summary is that I consider one  
of the main benefits of the reworking of XTM to be that it allows us  
to simplify the syntax and the specification by dropping XLink. XTM  
1.0 contains lots of things that were dropped in in 2000 because  
somebody thought they were a good idea, and everybody thought that,  
well, it couldn't hurt. A large number of these things have since  
proven to be anything from warts to real pains, and personally I  
think we should make use of this chance to learn from the past five  
years. (And before anyone gets upset: for all I know *I* may be the  
one to blame for XLink support being in XTM 1.0 in the first place...)

Input on this would be much appreciated.

> More generally, can I ask if anyone has written XSLT to transform  
> XTM 1
> to the proposed XTM 2 (and back)?

Not as far as I am aware. This is something that it would be great to  
have, actually, so anyone who wants to do this should feel encouraged  
to forge ahead.

--
Lars Marius Garshol, Ontopian               http://www.ontopia.net
+47 98 21 55 50                             http://www.garshol.priv.no