[sc34wg3] XLink support in XTM

[Murray Altheim]

Quoting Lars Marius Garshol <larsga at ontopia.net>:
>
> * 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.

No value? You get a linking model, semantics and syntax. If you drop
XLink the standard will have to describe those three things (unless
you're willing to do the brain-dead thing that a lot of language
designers do and just leave it to the imagination, as was done in
HTML). As for relating to two standards, that's a silly argument.
We're already relating to many standards -- the idea that XLink is
overhead is certainly not borne out in implementations, and if the
amount of space in the standard to make reference to XLink bothers
you, there's a lot more important things to be bothered over.

And just to be clear, in 2000 there never was much of an effort to
push the idea of a generic link processor. XLink was chosen because
it provides an XML-based linking model -- we didn't have to invent
a proprietary one. We felt it was important to be part of the XML
family. If XLink hasn't taken off as fast as was hoped, blame TimBL
(and ask anyone on the XLink team what kind of nonsense they've had
to deal with from the W3C).

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

I'm not sure where you got the idea that XLink was made for "document"
standards -- ask anyone on the XLink team and you'd find that it was
designed as the linking model for any and all XML markup languages, of
which XTM is certainly one. Integrating XTM with other XML markup
languages is enormously simplified if each one uses XLink rather than
creating their own proprietary linking language, which is what you're
proposing. And with XTM 2.0 permitting arbitrary XML markup, I would
think the argument for XLink would be even stronger now than in 2000.

As for ease of typing the syntax, that never was a priority, nor should
it be. Nobody in their right mind would spend much time typing XTM; it
wasn't meant as an authoring syntax.

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

This wasn't a big deal in 2000, nor is it now. You seem to like RDF,
whose community thinks nothing of having a dozen namespaces in one
document. We have two in XTM, one for the Topic Map semantics, one
for the XML-based linking semantics. That seems pretty sensible to me.

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

It's a default attribute -- big deal. As for trouble, I have never
heard of any. The #FIXED attribute is there to let implementors know
it's a fixed type as much as it is there for machine processing.
Remember, we're designing a language here, not a schema. It just
happens that DTDs are a good language for specifying languages (i.e.,
a good balance of human readable vs. machine readable, something that
neither XML Schema or RELAX NG are not). Once the language is designed,
there could be inumerable schemas (i.e., in multiple schema languages,
for different purposes, etc. -- read Eve Maler's book if this is still
a question).

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

Simplifying the syntax at the expense of dropping the linking semantics
seems to assume that the corresponding language ambiguity is acceptable.

I believe I was the one who argued most vociferously for XLink, so I'll
take the blame. As for a lot of things that were good ideas in 2000,
you might remember that there are some of us who think a great number
of the decisions you're making in altering XTM from 1.0 to 2.0 to be
in error. I just got tired of fighting with you all and saw little to
no result in doing so (and lately I have had zero time to contribute).

> Input on this would be much appreciated.

In summary, if you drop XLink I believe you would have an absolute
requirement to provide an alternative linking model roughly equivalent
to what XLink currently provides. By using XLink all that work is done
for you. This was the argument in 2000 and is still valid today. If
XTM drops XLink it will have a proprietary linking model, which will
make it more difficult for designers and implementors to integrate XTM
with other XML markup and applications. I'm not sure how the benefits
of dropping it could possibly compare with that, on balance.

Murray

...........................................................................
Murray Altheim <murray06 at altheim.com>                              ===  = =
http://www.altheim.com/murray/                                     = =  ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk               = =  = =

      In the evening
      The rice leaves in the garden
      Rustle in the autumn wind
      That blows through my reed hut.  -- Minamoto no Tsunenobu