Summary by: Stuart Williams
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 firstname.lastname@example.org 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.
 TAG F2F Summary on xlinkscope-23.
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
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) "...you 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):
Points of information during the discussion:
Proposals considered during the discussion:
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.
[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.
Critical discussion seems to be largely centred on the threads:
|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]|
|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], [
[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], [
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.]
|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."||
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 :
is contrasted with a design that uses nested elements to carry linking references and per reference meta-data:
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."
|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:
Several alternate markup designs are proposed:
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:
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
Content authors learn by example - view source. [ Tim Bray]
Elliotte Rusty Harold argues that the use of nested simple links ought to be sufficient:
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 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. [
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]
|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].||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], [
[ 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.
|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].|
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.
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 is a placeholder for technical questions that have occurred during the process of summarising.]
Last modified: $Date: 2002/11/01 14:45:13 $ by $Author: swilliam $. $Revision: 1.10 $