Summary of Technical Discussion of TAG Issue xlinkScope-23

Summary by: Stuart Williams

0.    Scope and Status

This is the result of two actions placed on the author by the TAG:

The purpose of this document is to summarise the major technical points in the discussion of TAG issue xlinkScope-23. The document summarises discussion of the issue within the TAG up to and including the September TAG F2F and the major technical points discussed on 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.

[2] TAG F2F Summary on xlinkscope-23.

0.1 Table of Contents

1.    Summary of TAG Discussion

2.    Summary of email on www-tag

2.1      Discussion critical of XLink/Hlink

2.2      Forward-looking discussion

2.3      Points of Information

3.    Question(s)

1.    Summary of TAG discussion

The genesis of xlinkScope-23 is summarised in the TAG issues list. The issue was raised with the TAG by Tim Berners-Lee  as "...there is a question as to whether for any URI parameter, xlink:href should be used." He also offers own answer to the question which "...depends on whether the document type is a human-readable hypertext document, when generic hypertext xml tools would benefit from knowing what is a link, and whether significance of the URI in question is a hypertext link or something different." The TAG accepted the issue at its meeting of 17th June 2002. Technical discussion centred on whether XLink was intended for hypertext linking and UI centric applications; whether participants had a common understanding of the term hypertext; and whether XLink has broader scope than hypertext linking. Opinions varied amongst the TAG. There was sufficient majority to accept the issue for further discussion, with a degree of understanding that the process of resolving an issue does not necessarily lead to a TAG finding. There was objection to making this a TAG issue from David Orchard and Paul Cotton. 

The TAG asked Tim Berners-Lee to 'take ownership' of the issue which resulted in a Design Issues note "When should I use XLink?" This note reiterates the original question, offers 3 possible responses  1) " don't have to unless there is some functionality of xlink which you would like to lever." 2) "You should use xlink whenever your application is one of hypertext linking..." 3) "You should always make an XLink whenever you make a reference with a URI,...". The note argues the case for the second of these options, it also discusses the use of the term hypertext.

The TAG discussed the issue again on 1st July 2002 without resolution. The discussion touched on the meaning of unqualified attribute names, mixed use of XML languages, language mixing in RDF, distinction between links and hyperlink and links of various kinds (non-specific). 

The TAG felt constrained in its ability to discuss HLink prior to its public publication and requested the HTML-WG to publish the HLink WD. Substantive TAG discussion of xlinkScope-23 occurred again on 16th September 2002. Discussion included: noting stylistic difference between XLink and HLink; noting that it might be appropriate to depreciate XLink; a strong preference for a single approach to linking in XML;  little implementation of XLink; intended usage of XLink; markup style preferences (Tim Bray - verbose, obvious with subelements and no indirection; TBL  inlined rather than in schema;); deprecation of XLink. Further discussion scheduled for TAG September F2F.

The TAG met F2F 24-25 September 2002 and discussed xlinkScope-23. TAG member positions expressed at the meeting were (summarising  and reordering from the minutes - take the minutes as authoritative):

  1. NW:
  2. CL
  3. TB:
  4. RF:
  5. DC
  6. TBL:
  7. DO:

Points of information during the discussion:

  1. Mozilla supports simple (but not extended) XLinks.
  2. SVG uses Xlink.
  3. XBRL uses extended XLinks.

Proposals considered during the discussion:

  1. Could declare the closed. XLink exists and is available for use.
  2. Could assert that TAG thinks that there are substantial benefits to having a single approach to hypertext linking in XML for UI oriented XML applications - but don't say which approach the TAG favours.
  3. Could ask the W3C to depreciate XLink... it hasn't caught on.
  4. Could take the view that HLink as it stands is not a productive direction for a W3C WG.
  5. Could recommend that XLink gets fixed to meet the requirements of others.
  6. Could abandon XLink multi-ended links.
  7. Could suggest that simple xlinks be used for simple links.

Discussion at the F2F concluded with a proposal from Tim Bray "TB: So HTML WG SHOULD use XLink for XHTML 2.0 unless there is substantial technical reason why not." further clarified by Dan Connolly with "DC: We are not asking for explanation at this point. TAG simply suggests that the HTML WG SHOULD use XLink. On the basis that fewer technologies is better for the world." Action to Norm Walsh to draft an email to the HTML-WG expressing the TAG's opinion. Norm's draft was reviewed by the TAG on 25th September which resulted in the postings to www-html-editor [missing from archive] and www-tag.

2.    Summary of email on www-tag.

[This summary focusses mainly on the threads that arose after posting of the TAG's opinion further threads could be mined from the period when the issue was first raised with the TAG - the discussion above has focussed largely on the records from TAG telcon and F2F meetings.]

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.

2.1    Discussion critical of XLink/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].

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] [ Tim Bray].

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


XLink is good for link metadata.

Point Counterpoint
[ Chris Lilley] expands the point that in multi-ended linking situations, the use of sub-elements to carry the underlying linking reference and metadata about the referenced resource  leads to a design with a regular structure for annotating links.  A design that carries metadata for linked resources on attributes :

<img src="foo.svg" 
     title="my cat" 
     longdesctitle="about my cat"

is contrasted with a design that uses nested elements to carry linking references and per reference meta-data:

<switch xmlns:xl="
  <img xl:href="foo.svg" 
         <span class="example>marked-up</span>
  <longdesc xl:href=""
    <title>about my 
      <span class="example>marked-up</span>cat
    <span class="example>marked-up</span>
    alternate text

Chris argues that the latter is a better design if you intend to add multi-ended linking; link meta-data and do a good job of internationalisation. He concludes "But HTML already has link metadata, might or might not add multi-ended links, and hopefully wants to do a better job with titles in the future. Thus, XLink, which has as a design goal the association of link metadata, is a good fit here."


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"/>


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:actuate="onLoad" x:show="embed"/>

    <arc x:type="arc" x:from="thisImg" 

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:

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

Or even

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

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

2.2    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 on the proposal being focussed on a future XLink, say 1.1 or 2.0.

2.3    Points of Information

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

3    Question(s)

[This is a placeholder for technical questions that have occurred during the process of summarising.]

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.

Last modified: $Date: 2002/11/01 14:45:13 $ by $Author: swilliam $. $Revision: 1.10 $