The Problem with XLink

1 Introduction

XLink is not exactly taking over the world. I believe that there are a variety of reasons for this, but the most deep problem is that XLink exacts a cost and pays back nothing in return.

There are two primary reasons to adopt standards. One is to improve interoperability between producers and consumers of software. The other is to leverage standardized software components that can work with the standard. XLink fails in both categories.

2 XLink and Interoperability

When I produce XML data, I am basically telling the consumer: "Here is some information that has been serialized as a tree. You can parse it and interpret it." The interpretation is based on the consumer's a priori knowledge of the meaning of the element types. This is typically communicated through prose documents, specifications and books. The problem is that XLink does not reduce this burden at all. Consider the following example from the XLink specification:

<my:crossReference
  xlink:href="students.xml"
  xlink:role="studentlist"
  xlink:title="Student List">
Current List of Students
</my:crossReference>

In order for a client application to work with this data, it would need to understand what my:CrossReference means. It could infer from the use of the XLink specification that the element is a link, but it would not know the meaning of the link so the effort to program an interpretation of this element is not much reduced from a simpler vocabulary-specific formulation:

<my:crossReference
	href="students.xml"
 title="Student List">
Current List of Students
</my:crossReference>

You could argue that XML itself has this same problem. After all, you can't interpret XML until you understand the particular vocabulary. But that is because XML is designed to give you a different kind of economy of scale. XML allows the reuse of components such as DOM implementations, schema implementations, XSLT processors and schema processors.

3 XLink and Components

Even if XLink did not directly provide interoperability, it could be a terrific boon to software developers and indirectly to interoperability if it provided a basis for various kinds of "linking engines" that were significantly easier to work with than proprietary linking schemes. For instance, before XML existed, most people parsed proprietary data formats "from scratch." This was tremendously expensive so the availability of XML parsers drastically slashed the cost of parsing information. But XLink does not change the difficulty of parsing links by very much.

4 XLink and Other Standards

XML describes a tree structure. We always knew, however, that that was not enough. So XML also has XML Schema, for constraining tree structures, the DOM, for working with the structures from programming languages, XSLT for processing them in a language-independent manner, and CSS for applying style. XLink is for defining graphs. But it does not have a schema language for constraining links. It does not have a standardized API. XSLT has no support for it. CSS has no facility for rendering XLinks graphically.

Of course you can use XML Schema and XSLT and CSS and the DOM with XLinks. But you can just as easily use these languages with a vocabulary-specific linking language. XLink will have much better economies of scale if it is integrated with other W3C specifications. Unfortunately I have heard very little talk about this sort of thing at the W3C.

5 XLink Generality

The W3C suggests that XLink is for document-like data. Roughly speaking, document-like data is data that is processed by a machine only to directly display for human beings. It makes no sense to restrict XLink in this way and actually harms the growth of XLink even in this market.

First, the very distinction is bogus. A well-written XML schema will have significant documentation in it and will be equally useful for machines and humans. Should the schema therefore use XLink or not? The very genious of XML is that it integrates the data and document processing worlds.

Second, XLink will not achieve economies of scale if it is restricted to only a small subset of the XML processing world. For instance, if I developed link checking software I would want to sell it to people making both "document-style" and "data-style" XML. If my software needs to deal with a variety of linking styles then I get no benefit from XLink whatsoever. I will just end up treating it as one more style.

Third, XLink is already more popular in data-like vocbaularies than in document-like ones. The W3C should support this trend, not deprecate it. The W3C should use a single linking standard for all types of documents without making an artificial distinction between document-like and data-like vocabularies.

6 XLink's Costs

XLink has real costs to a language designer. First, you must read the specification and understand it. Then, you must add the XLink namespace to all of your documents, schemas, stylesheets and programs. Then, the consumers of your information must go through the same process. It is much cheaper to say: "just treat the location attribute as a link". This, fundamentally, is XLinks problem. XLink either needs to become cheaper than the alternative or provide some significant functionality in terms of interopreability or associatd standards. Today it does not and it is therefore no surprise that it is widely ignored.