[sc34wg3] XLink support in XTM

[Lars Marius Garshol]

* Murray Altheim
>
> 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've put forward my rationale for this.

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

No, I agree that XTM 1.0 using XLink counts as an argument in favour  
of XLink. For me it doesn't count very heavily, though.

> You obviously by your approach to XTM 2.0 put very little weight on  
> stability or continuity.

Heh. Anyone who was in Atlanta can testify that I did what I could to  
stop XTM 2.0 from happening at all, precisely because I preferred  
stability. In all the work we've done on this since 2001 I've tried  
to keep the changes to the XTM syntax as minimal as at all possible.  
But once we've changed the XTM namespace we've effectively changed  
everything, anyway.

> 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: [...]

These definitions are fine.

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

Yes. The meaning of a reference is expressed in other ways in XTM,  
however, so we can't make use of this (as it would make it hard to  
connect the two ways of expressing the meaning of the same thing).

> Links also have behaviours, as described in #3, and as specified in  
> XLink via its 'show' and 'actuate' attributes.

Yes. None of these attributes are allowed in XTM 1.0, though.

> Neither identifiers nor references have behaviours.

Not in and of themselves, no. However, XTM 2.0 describes fully what  
behaviour is required from processors.

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

Are you joking? The conformance section is pretty clear on this. It  
says a processor conforms if:

   * The XTM processor shall reject any input which is not a conforming
     XTM document.

   * The XTM processor shall produce a representation that is isomorphic
     to the data model instance created by the procedure given in Clause
     4 for all XTM documents.

It also says very clearly that <mergeMap/> references must be  
traversed by the processor. It doesn't say this about any other  
references, for the simple reason that traversing these is not  
required. So as far as I can tell we are covered on this.

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

Yes, Jirka Kosek already pointed this out, thus demolishing one of my  
arguments against XLink.

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

As far as I can tell, the baggage amounts to behaviour, which is  
specified in the current draft anyway, and which would have to be  
specified even if we used XLink, because we require specific  
behaviour for <mergeMap/> that XLink doesn't specify.

> I don't know how I can be more explicit that this, [...]

If you've now covered the benefits XLink bring to XTM in full I don't  
see that you need to.

> 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 only specifies one action (unless you count merging): you must  
traverse <mergeMap/> references.

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