Proposed XLink Improvements

Volume 8, Issue 14; 31 Jan 2005; last modified 08 Oct 2010

The W3C XML Core Working Group has proposed a few modest improvements to make XLink more usable.

Despite some controversy, and while hardly setting the world on fire, XLink has seen some implementation (SVG, XML Topic Maps, XBRL, etc. See Robin Cover’s excellent (as always) summary for more details). What's more, I think there's plenty of hope for continued adoption. I'm currently using it in DocBook NG and I hope to extend the stylesheets to provide at least some support for extended links.

But this essay is not intended to spark controversy. I've had enough of that recently. You like XLink, you hate it, you haven't made up your mind; it's all good to me.

Even the proponents of XLink, I think, will grant that it has at least one significant usability flaw. In order to define a simple link, you must specify not only the hypertext reference, but also the link type:

<myLink xlink:href="someURI" xlink:type="simple">hot text</myLink>

XLink was designed in the age of DTDs and the idea of relying on the DTD to provide default attribute values to work around this inconvenience didn't seem unreasonable. But it sure does now, especially in an age of well-formed documents validated by many different schemas. The honest truth is, I don't think it was even a good answer in the DTD days, not really, but I didn't notice at the time (I won't attempt to speak for others).

Recently, the XML Core Working Group published a very short note, Extending XLink 1.0 , that describes a few small changes that could be made to XLink to improve it's usability.

The chief proposal is that the XLink link type should be an application default. In other words, an application that sees

<myLink xlink:href="someURI">hot text</myLink>

should infer that myLink is an XLink simple link (in the absence of any other declaration that provides a value for the xlink:type attribute). That single change will significantly simplify the authoring process and separate XLink from any particular schema requirements.

Because that construction is not valid now, this change cannot break any existing, valid documents. Any existing documents that don't specify a link type will go from being invalid to being valid simple links, and I can't imagine that answer being wrong in any but the most pathological cases.

The other changes, explicitly reserving other attributes in the XLink namespace, explicitly allowing IRIs, and providing some additional non-normative schemas, are all nearly trivial.

I hope the community can come to consensus that these are small and reasonable changes that can be made without harm irrespective of anyone's position on the merits, or lack thereof, of XLink as a whole.


Great! With this change in XLink I would not be relucting XLink in DocBook NG :-D

—Posted by Jirka Kosek on 01 Feb 2005 @ 10:47 UTC #

Even when using dtds the type attribute was/is a real pain.

MathML allows xlink on essentially every element, but in practice it's used fairly infrequently (most symbols in most mathematical formulae are not links) In an early draft of mathml2 we defaulted the xlink type attribute but implementors commented that this made the resulting DOM appreciably larger for no good reason, every element child (and mathml often has an element for every character of data) aquired a new attribute node. So sometime before REC we changed that to just make xlink:type be #IMPLIED, so to comply with xlink as it currently is, mathml users have to explitly add xlink:type attributes on any link. The proposed change would be a big improvement.

—Posted by David Carlisle on 01 Feb 2005 @ 11:57 UTC #

Because that construction is not valid now, this change cannot break any existing, valid documents. Any existing documents that don't specify a link type will go from being invalid to being valid simple links, and I can't imagine that answer being wrong in any but the most pathological cases.

What about the combination of new documents and older software? It sounds like people will have to keep on specifying the extra attribute because older software would otherwise break. Isn't the whole point of specifications to keep things interoperable?

PS: No <blockquote> allowed in comments?

—Posted by Jim on 02 Feb 2005 @ 03:06 UTC #

I imagined the xml:id spec would form the basis of a simplified XLink/Include model, or is it just a case of too little, too late?

—Posted by Paul Downey on 02 Feb 2005 @ 10:03 UTC #

Even when DTDs were required and architectural forms seemed to be a winner, some of us doing well-formed work prior to XML considered the DTD to just be a specification and that #FIXED atts represented hardwired requirements. In other words, there should always be a way for the well-formed document to point back to some record of authority without requiring it to actually fetch that and process it. That ROA should be able to contain all of the (dare I use the word...) DOCUMENT TYPE information. It seems to me we bash on namespaces because they do some things awkwardly and don't use them for something they can do pretty well. Specifying where to find application defaults just in case one wants to check the application contract should be one, and before we dive into the semantic web, maybe we should have the easiest things first.

—Posted by len on 02 Feb 2005 @ 03:43 UTC #

I welcome the publication of this Note. I hope it heralds a renewed activity from the W3C on XLink.
To the specifics of the proposal - defaulting the type attribute might have some small influence on a language designer that is wavering between using XLink's simple link and just putting href directly into the target language. To be honest, I don't have a good feel for the number of languages under construction, or at a point where they could be revised to take advantage of this change.
Speaking more directly about XBRL - XBRL uses extended links to a far greater degree than simple links, so this change would have relatively minor impact on any future revision of XBRL. The small change that would affect XBRL in a more positive and pervasive way would be to issue an official W3C XML Schema for XLink 1.0. Currently, XBRL relies on schemas of its own design for XLink.
What XBRL really needs is a restart of XLink activity. We need a way of specifying our own hyperlinking facilities in terms of standard building blocks, rather than two specific kinds of media hyperlinks (too small and jumbo). For example, the common way extended links are used in XBRL is to express a bi-directional relationship between abstract concepts. As such, we would prefer locators with href=QName instead of href=IRI, and we don't need browser-style traversal semantics. In another use of extended links, the locators should be restricted to pointing at elements within the surrounding xbrl element. It would be nice to move that constraint from the text of the spec to a machine-readable definition. I'm thinking of a set of attributes that can appear within the XML Schema definition of an attribute such as xs:attribute name="href" type="xdt:URI" xlink:use="pointer" xlink:constraint=" ...XPath goes here... "
OK, that's my vision of XLink 2.0 as a Hyperlink Language Construction Set. In the meantime there are other small improvements in XLink that could be accomplished in the 1.1 release contemplated by the Note. One already noted is an official schema.
Another is concrete elements for simple and extended links for those that want to use them. For example, in XBRL every linkbase uses the same loc element, and the customised arc elements all are members of an arc substitution group. Publishing a schema for these concrete elements would be a help.
Another helpful change would be to remove the behavior attributes in favor of something better integrated with the XML Events spec.
XBRL was forced to invent a way of describing how linkbases from different authors interact. This is actually out of scope for a single language. We would prefer that XLink itself address these issues. This is simply the recognition that of the kinds of things links can point to and be about, other links and linkbases can be the most interesting.
XBRL also has created some way to define new roles and arc roles. Some of that material may be generally useful. For example, arc roles can specify whether cycles are allowed to exist.
I hope that a willingness to discuss changing XLink will eventually lead to a willingness to address the even graver problems of XPointer. XPointer needs to be finished, and it needs to be continued. XPointer needs a query() scheme that will allow an arbitrary XQuery query.
After a certain amount of carping, practically all XBRL developers have become big fans of the way XLink works in XBRL. I think XBRL uses every facility of XLink except the behavior attributes, and we are still discovering more ways to use it. It is because XLink is such a powerful and successful tool that we want more!
Let me conclude by saying that, notwithstanding my use of "we" above, these are my personal opinions, not those of my employer or XBRL International.
David vun Kannon
Senior Manager

—Posted by David vun Kannon on 09 Feb 2005 @ 07:18 UTC #

Much as spent quite a while reminding W3C folks that XBRL was their biggest and most important XBRL use case, I do think now that the XBRL should move on. The time is right for a Semantic Web version of XBRL, by which I mean RDF/Topic-Maps/OWL(Lite or Heavy). There really isn't so much to lose, and a lot more software support to gain. Let's see XLink as what it is and was, a worthy attempt to solve half the problem. Cheers, Tony.

—Posted by Anthony B. Coates on 11 Feb 2005 @ 08:26 UTC #

This change would also legalize the common practice in SVG implementations. SVG uses xlink:href extensively, and relies on the DTD to add xlink:type="simple" wherever appropriate. But even in images with no DTD reference (e.g. those embedded in XSL-FO), no author ever sets an explicit xlink:type; and I am not aware of any SVG processor that cares about it.

—Posted by Nikolai Grigoriev on 16 Feb 2005 @ 10:58 UTC #