[sc34wg3] XLink in XTM

[Murray Altheim]

Lars Marius Garshol wrote:
> I've spent some time on the new XTM syntax specification this evening,
> and realized that there are quite a few XLink-related issues that we
> have never thought through in any depth.

I'm not sure who "we" is, but I can assure you that I spent a *great*
deal of time on the XLink issues of XTM, and conferred with a number
of linking experts including Eve Maler, Steve DeRose, and a few
others on the XML Linking WG at the time. I looked at every possible
XLink feature we could have used. What we ended up with is what was
possible, i.e., defined within the XLink 1.0 Recommendation. I've
expressed my regrets and disappointments with this previously. Any
further markup would be stepping outside the boundaries of XLink and
therefore not be supported by XLink-compliant tools -- we can't rely
on extensions to XLink.

> I've added these issues to the current working copy[1], but I think it
> may be good to have a discussion about this via email before London,
> hence this posting.
> 
> The first issue is xtm-xlink-type:
> 
>   Should all element types which have xlink:href attributes also have
>   xlink:type attributes? If so, which type?
> 
> The XLink Recommendation requires conforming elements to have this
> attribute, so it appears that we are not conformant unless we add them
> to the syntax.  It seems to me that 'simple' is the right choice for
> xlink:type if we do add this.

If you look again you'll see that the XTM 1.0 DTD has a FIXED attribute
for "simple" already.

> The second is xtm-xlink-actuate:
> 
>   Should all or some element types which have xlink:href attributes
>   also be given an xlink:actuate attribute? If so, what should the
>   legal range of values be?
> 
> I added this because this feature is part of XLink and it seemed that
> it could be used by XTM authors to specify whether or not they want
> XTM implementations to actually traverse the link and load whatever is
> at the other end. How useful that is is an open question, but XLink
> does at least give us the possibility.

I believe we went through this in some detail during the development
of XTM, and we didn't include this because none of the definitions
for the 'actuate' attribute make any sense for XTM; 'actuate' is all
about presentation, and XTM documents aren't presented, they're
processed. Also, link traversal varies in XTM in different contexts.
'actuate' was designed really only for presentation of textual
documents -- this is quite clear if you read the definitions for its
values: "new", "embed", "replace", "other" or "none". For XTM it'd
always have been "other" or "none".

> The issue xtm-fixed-attributes also bears thinking about in this
> context:
> 
>   Attributes declared as #FIXED in the DTD can not be guaranteed to
>   always be present in the XML document as parsed, either because
>   there is no DOCTYPE declaration, or because the parser does not read
>   the DTD. This affects both namespace and XLink parsing, which again
>   affects procedure used to recognize element types.
> 
> Opinions? Comments?

XTM 1.0 documents are by definition valid according to the DTD. If
not, they're not XTM 1.0 documents. The DTD does guarantee that,
and you can't legislate bad behaviour, i.e., if an application
does or doesn't read the DTD. You can say the application simply
doesn't know if the document is XTM 1.0 or not if it doesn't.

BTW, these issues don't change with other schema languages, only get
more complex and less widely supported.

Now, if the W3C were to issue a new version of XLink that defined
linking structures deeper than parent-child, that would be interesting
news...

Murray

......................................................................
Murray Altheim                  <http://kmi.open.ac.uk/people/murray/>
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK

     "In Las Vegas Mr Gates also demonstrated a prototype
      fridge magnet which can be programmed to receive traffic
      reports, sports results and advertisements from local
      restaurants using the same FM signal as the wristwatch."
                                  -- The Guardian, 10 Jan 2003.