Summary of Technical Discussion of XLink/HLink on www-tag

Summary by: Stuart Williams

Scope and Status

The purpose of this document is to summarise the major technical points and counterpoints raised subsequent to the TAG opinion reported in [1,2]. The intent of this document is to act as a (hopefully) compact, complete and balanced record of the technical points raised in the discussion. It is not the intent to prejudice the debate or to be judgemental on the arguments advanced.

This content document is subject to change with the intention addressing any significant errors or omissions

[1] http://lists.w3.org/Archives/Public/www-tag/2002Sep/0183.html
[2] TAG F2F Summary on xlinkscope-23.

Discussion Summary

Technical discussion has progressed through a couple of phases, initially centred on critiquing the relative merits of XLink and HLink and then more recently focussed on possible changes to XLink that might make meet the needs of mark-up language designers in general and the XHTML-WG in particular.

Critical Discussion of XLink and HLink

Critical discussion seems to be largely centred on the threads:

Content author need to be able to build on existing HTML knowledgebase

Point Counterpoint
XHTML authors need to be able to leverage their current knowledgebase. "Nor can they be required to use a bunch of arcane attributes on every linking element just because there is some approved W3C Recommendation that is sort of in this space that _could_ be used." [ Shane McCarron] Since XHTML 2.0 is will not be backward compatible with XHTML 1.0 HTML content authors transitioning to XHTML 2.0 will have to update their content whether or not XHTML 2.0 adopts Xlink. [ Didier Martin] [ Elliotte Rusty Harold], [ Roy Fielding]

HTML needs multi-ended links, single locator per start-tag is too restrictive.

Point Counterpoint
The XML 1.0 restriction of a single instance of a given attribute per element start-tag effectively prevents start-tags carrying multiple locators, different locators for different purposes, eg. image reference, long description, scripting behaviour. [ Simon St. Laurent], [ Steven Pemberton], [ Steven Pemberton].

[Arguing for extensibility by adding distinguished attributes to elements.]

 Element content containing child elements each carrying an xlink:href locator is better markup design for linking situations that involve arbitrarily many linked resources. It also permits much a more flexible approach to metadata about the link/ linked resource. [ Tim Bray], [ Tim Bray]. [ Elliotte Rusty Harold], [ Chris Lilley].

In the thread XHTML needs multi-ended links, [ Tim Bray] and [ Ann Navarro] conclude that revising XLink to provide more defaults for attribute values could enable a more acceptable 'generic' linking mechanism. This led to [ Tim Bray] proposing "infer xlink:type" (more below).

[Arguing for extensibility by adding nested elements.]

Elements good for I18N text.

Point Counterpoint
Without prejudice to either side of the argument [ Misha Wolf] remarks "We find that wherever text (as opposed to an item from a set of fixed values) is used, it is good for I18N to *allow* elements to be used. Various languages/scripts require markup, eg for BiDi or Ruby (furigana). This, obviously, doesn't fit well with attribute values."

 

Usability with respect to content authoring (XLink verbose and error prone).

Point Counterpoint
Xlink extended links are verbose, difficult to understand and easy to get wrong. [ Steven Pemberton], [ Micah Dubinko]. The archetypal example use case is to achieve Xlink functionality equivalent to:

<img src="someImageUri" longdesc="someLongDescUri"/>

Several alternate markup designs are proposed:

<img xlink:type="extended>
    <src xlink:type="locator" xlink:href="someImageUri"/>

    <longdesc xlink:type="locator" xlink:href="SomeLongDescUri"/>

</img>

However, others would argue along the lines of Micah Dubinko that this is an extended link that involves only two linked resources (referenced by the xlink:href attributes) and does not involve the apparently implicit <img> element. To form the intended link requires the inclusion of a local resource to participate in the link and optionally the addition traversal arcs to attribute arcroles and traversal semantics, yielding:

<img x:type="extended>
    <src x:label="imgSrc" x:type="locator" x:href="someImageUri"/>

    <longdesc x:label="lgDescSrc" x:type="locator" x:href="SomeLongDescUri"/>

    <local x:label="thisImg" x:type=resource/>

    <arc x:type="arc" x:from="thisImg"
         x:to="imgSrc"
         x:arcrole="http://example.org/embeddedImage"
         x:actuate="onLoad" x:show="embed"/>

    <arc x:type="arc" x:from="thisImg" 
         x:to="lgDescSrc" 
         x:arcrole="http://example.org/longDescription"/>
</img>

Similar examples have circulated based on complex <object/> and <script/> elements.

 DTD and Schema defaulting can be used to default many of the Xlink attributes to reduce the verbosity of instance documents. 

HTML needs multi-ended links and XLink is much less verbose and much more comprehendible than many javascript 'hacks' use to achieve multi-links that XLink is capable of expressing. [ Tim Bray]

Content authors learn by example - view source. [ Tim Bray]

Elliotte Rusty Harold argues that the use of nested simple links ought to be sufficient:

<img>
    <src x:type="simple" x:href="someImageUri"/>
    <longdesc x:type="simple" x:href="SomeLongDescUri"/>
</img>

Or even

<img x:type="simple" x:href="someImageUri">
    <longdesc x:type="simple" x:href="SomeLongDescUri"/>
</img>

From an XLink point-of-view each of these represent two unrelated links, although an application may presumably infer some association on the basis of the semantics of the enclosing <img> element and its associated content model. [This trailing presumption is mine... such an association would suffer from being hidden from an Xlink aware 'generic' XML processor.]

Micah Dubinko also states "For completeness, I should say that HLink also isn't up to the job of making the example code work properly. So, can we agree that there's more work to do and move on?"

DTD and Schema defaulting can help make XLink instances less verbose.

Point Counterpoint
DTD and Schema defaulting can be used to default many of the Xlink attributes to reduce the verbosity of instance documents. [Xlink],[ Norm Walsh],[ Norm Walsh] (and others). Math ML implemented simple Xlinks. It chose Xlink because it was there. The requirement to instantiate an xlink:type attribute in conjunction with every instantiated xlink element is problematic. Fixed DTD and Schema defaulting of xlink:type assert such an attribute even when the host element is not being used for linking. [ David Carlisle]

Schema and DTD defaulting techniques used in DTD/Schema for languages like SVG to minimise the use of xlink attributes in document instance still result in "useless" overhead in corresponding infoset/DOM [ Robin Berjon]

Remapping approach provides attribute/element naming flexibility.

Point Counterpoint
HLink enables the (in-band and out-of-band) mapping of linking semantics onto the elements and attributes of a markup-language. This enables the description of linking semantics of a markup language rather than imposing the use of attributes and elements from a linking integration language. The emapping approach avoids the limitations of that prevent XLink elements being repeated on a single start-tag. [ Steven Pemberton], [ Simon St. Laurent].

Alternate CSS like syntaxes for an HLink like approach are proposed [ Eric van der Vlist], [ Jeni Tennison], 

 Remapping approaches such as HLink impose an additional burden on so-called 'generic' XML tools. In order to harvest links it becomes neccesary for them to be able to process the remapping language (HLink in this case). This places additional burden on tools like XSLT.  [ Dare Obasanjo], [ Didier Martin], [ Norm Walsh].

[ Eric van der Vlist] argues that XSLT (spec.[?] and tools) need not be updated. Appropriate filters can be used to pre-process the content language into a form that 'exposes' links in a generic way.

Further discussion on XSLT processing of HLink with examples from [ Eric van der Vlist] in the the thread starting at [ Didier Martin].

Why not use RDF for describing linking relationships?

Point Counterpoint
The thread Why not XHTML+RDF? was Re: Links are links discusses the use of RDF both as a way of describing linking semantics [ Jonathan Borden] and as a way of providing link metadata [ Tim Berners-Lee]. Responses on this thread indicate that some find RDF syntax as "invasive" or "unusable" for content authoring as XLink [ Paul Prescod], [ Ann Navarro].

Forward looking discussion

Discussion about possible technical ways forward is rooted in the threads:

The ideas developed in the discussions summarised below principally discuss small changes that could be made to XLink to better address the needs of XHTML in particular and XML based mark-up languages in general. Three concrete ideas emerge, two of which address the need for multi-ended links, 2 and 4 below, and one that proposes a new xlink element-type that implicitly includes the linking resource as a participant in an extended xlink, 3 below.

  1. Early on in the discussion Steven Pemberton  argues that XLink and HLink are both parts of a single story on generic linking. HLink is positioned as a language for mapping Xlink concepts the elements and attributes of markup languages.
  2. Micah Dubinko makes a "modest proposal" to define xml:href and xml:src attributes whose presence on an element implies <a href="..."> or <img src="..."> semantics. Micah proposes that this approach might address the HTML-WGs "...objection to having the limit of a single attribute per type." Micah further explains his CSS like idea of for dealing with 'actuate' and 'show' behaviour.
  3. Micah Dubinko proposes a new xlink:type value, 'local-extended' to implicitly include the enclosing element as a resource within the extended link rather than having to cite it explicitly with a resource xlink element. This receives a generally positive response [ Tim Bray] with some lingering questions about xlink arcs.
  4. As a consequence of the " XHTML needs multi-ended links" thread between Tim Bray and Ann Navarro, Tim Bray  proposes a revison to xlink whereby if absense, the value of xlink:type is defaulted as follows:

    If an element has xlink:href=, then
     - If its parent element has xlink:type="extended", infer xlink:type="locator"
     - Otherwise infer xlink:type="simple"

    This proposal also met with some favourable response [ Ann Navarro] conditioned the proposal being focussed on a future XLink, say 1.1 or 2.0.

Question(s)

On Xlink:

  1. What is the role of the 'host' language elements in determining the role of a resource or arc involved in an Xlink (extended or simple)? For example, in the img/src/longdesc case, role URI's could be assigned by say the XHTML-WG for use on role or arcrole attributes to assert that the role of a given resource in an xlink is say that of a long description or an image. However, as in the examples above, if the relevant resource is introduced by a host language element, that element itself potentially determines the role of the linked resource and may obviate the need to attribute role and arcroles to locators, resources and arcs.

Points of Information

  1. The attribute remapping in HLink may have some overlap with ISO Architectural Forms. [ Tim Bray]

Last modified: $Date: 2002/10/21 17:01:30 $ by $Author: swilliam $. $Revision: 1.2 $