Summary by: Stuart Williams
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.
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:
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] |
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.] |
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." |
|
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:
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
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:
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?" |
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] |
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]. |
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]. |
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"
On Xlink:
Last modified: $Date: 2002/10/21 17:01:30 $ by $Author: swilliam $. $Revision: 1.2 $