[sc34wg3] XLink support in XTM

Thu Apr 27 19:15:40 EDT 2006

Quoting Lars Marius Garshol <larsga at ontopia.net>:
>
> * Murray Altheim
>>
>> If you have read through the URI specification you would accept
>> that it does not provide a definition of linking, about linking
>> behaviour, and certainly nothing about providing a link syntax
>> that connects to that behaviour.
>
> I agree. The question is: does XTM need this? You think it does, I  
> think it doesn't. So the question then becomes, what do you think XTM 
> needs this *for*? What concrete benefit does offer XTM?

Lars Marius,

No, the logic of standards would not dictate that I need to now
justify why XTM 2.0 needs this. You are the revisionist. Since the
current standard, upon which the new draft is a proposed revision,
contains linking as specified via XLink, it should be up to you to
justify why XTM doesn't need to maintain its current specification
for linking. I am for the status quo, for the stability of the
current standard. But I can see you don't take such a conservative
approach to standards development, so I'll henceforth leave this
argument to rest, since you continue to refuse to respond to this
anyway. You obviously by your approach to XTM 2.0 put very little
weight on stability or continuity.

But to try to clear this up (if that is remotely possible), I hope
we can agree on this very simplistic definition of 3 things:

   1. identification - the act of identifying an object or resource,
      and the creation of a (unique-within-a-context) label or
      identifier for that object or resource. No action is implied.
      E.g., URIs.

   2. reference - to make reference to an identifier for purposes of
      pointing to some object or resource. No action is implied.
      E.g., XML Namespaces uses URIs (identifiers) as references to
      a namespace. These are called "URI references".

   3. link - to traverse a link is to use a reference (to an identifier)
      to perform an action, such as loading the referenced resource
      as a substitute for the currently-loaded resource (alink),
      inclusion, transclusion, etc.  The specific linking behaviour
      will depend upon the context in which the link is traversed.

Whereas identifiers and references are only identifying and pointing,
links can also have meaning (as in XLink via its 'role', 'arcrole',
and 'title' "Semantic" attributes, or in HTML's alinks via 'rel' and
'rev' attributes). Links also have behaviours, as described in #3,
and as specified in XLink via its 'show' and 'actuate' attributes.
Neither identifiers nor references have behaviours.

Now, URIs provide #1, and what you're proposing for XTM 2.0 provides
#2. XLink provides a complete specification for how to use #1 and #2
in providing #3.  Absent #3 in XTM 2.0 there is no specified action
implied for anything -- the document just sits there. It's apparently
then left entirely up to the implementor to figure out which URI
references are meant to be traversed as links, when, and what
behaviour those references take when they're traversed. Strictly
speaking, an implementor would be entirely within their rights to
create a compliant XTM 2.0 implementation that didn't do anything
with the document. If you look back into the XTM 1.0 specification
we made plenty clear what was supposed to happen with links, or at
very least we damned sure tried to.

XLink 1.1 [1] has even simplified alinks so that they are the
default link type (i.e., the 'xlink:type' attribute no longer
needs to be explicitly stated unless it's not a simple link):

   "If an element has an xlink:href attribute but does not
    have an xlink:type attribute, then it is treated exactly
    as if it had an xlink:type attribute with the value
    'simple'."     -- from section 4, XLink Markup Design

We don't need very much of XLink at all, just the basics of its
"simple" alinks. But with that we get the complete definition for
an alink, good baggage, all for the price of using the namespace.

I don't know how I can be more explicit that this, which is a repeat
of what I've been saying all along, and was the same argument used
in 2000 for inclusion of XLink in XTM 1.0. Since linking is in XTM
1.0 it would seem to be a requirement upon you to justify why it is
being removed, not for me to argue why it should need to remain.

I've never seen any justification for why XTM doesn't need linking.
DocBook uses linking (and will be using XLink in DocBook 5[2]), SVG
uses XLink linking[3]. And by any measure, XTM would be seen to be
an inherently more link-active document type than either DocBook or
SVG, one a spec for a technical document, the other vector graphics.

One of the articles[4] from 2002 about why XLink hadn't taken off
big time was justified because someone thought that Topic Maps (!)
were a potential substitute for XLink extended link sets, but that
was predicated on XTM 1.0, which uses the XLink specification of
alinks as the foundation upon which to create those more complicated
*linking structures*.

Notice I didn't say "identification" or "reference" structures, but
"linking" structures -- structures than specify action. Link isn't
just a word, it has meaning ("semantics" to the W3C folks). XTM 2.0
either links or it doesn't link, and if it doesn't link it doesn't
specify any action. XTM 2.0 would *do* less than DocBook, it would
be an entirely passive document type. I don't see how that can
possibly be justified. As I said, I see it completely incumbent
upon you to justify why XTM doesn't need linking before you remove
it from the ISO specification for XML Topic Maps.

I have no more to add to the subject. This message repeats once
again what I have been saying all along, hopefully in enough to
detail to be clear about anything I've not been clear about before.
But after all this effort, if XTM 2.0 does not specify linking I
won't be remotely surprised; in fact it's what I've sadly come to
expect.

Murray

[1] XML Linking Language (XLink) Version 1.1
    W3C Candidate Recommendation 28 March 2006  (very recent!)
    http://www.w3.org/TR/xlink11/
[2] DocBook 5.0b4
    http://www.docbook.org/xml/5.0b4/
[3] SVG 1.1 section on linking
    http://www.w3.org/TR/SVG/linking.html
[4] XLink: Who Cares? Bob Ducharme, xml.com. March 13, 2002,
    http://www.xml.com/pub/a/2002/03/13/xlink.html?page=1
...........................................................................
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