Several people made good points in a recent xml-dev thread begun by Andrew Welch’s posting titled Current Status of XLink. (The link above goes to the entry for Andrew’s posting on the thread index, a web page that includes links to some replies below Andrew’s entry; a different part of the same page lists the remaining thread entries. Note that the thread list indentation doesn’t always reflect the thread structure of the discussion.) The “what’s wrong with XLink” topic is a bit of a permathread on xml-dev, and this “Current Status of XLink” thread gives the flavor of several issues that will be brought to the table if the W3C ever convenes a Working Group to update or replace XLink. My favorite quote was from XSLT 2.0 spec editor and Saxon developer Mike Kay:
In my view the mess is because XLink simply doesn’t fit into the layering of the XML architecture. The whole point of XML is that you can choose any names you like for your objects and attributes, and give them any semantics that you like (typically captured in schemas and stylesheets). So why should relationships be different from objects and attributes, and require fixed names and fixed semantics?
Hyperlinking is something that belongs in the user interface layer, not in the stored information. The stored information needs to hold relationship information in a much more abstract form. The hyperlinks, like all other user interface objects, should be generated by the stylesheet. It’s because the hyperlinking community failed to recognize this that the idea failed to catch on. The other consequence of this is that there is a gaping hole in the XML story as to how abstract relationships should be modelled.
(For a nice example of hyperlinks being generated by the stylesheet instead of being stored in the data, see my last weblog posting.) Eric van der Vlist replied to the question ending Mike’s first paragraph above by pointing out that “one may consider that a markup that would have some support for describing graphs might be more useful than one that only supports trees,” and I replied to Eric that “I don’t think that addresses Mike’s point: why does markup that describes
graphs require *fixed* names and semantics?” And, because of Eric’s wish to use markup to describe graphs, I threatened to drag RDF into it, but I backed off.
I also liked Ari Krupnikov’s wish for a CSS “property that would turn an element into
a link. Something that would make it possible to replicate a/href only
on arbitrary elements/attributes, or even on character content.” It would be the fulfillment of what Mike was talking about: parts of your data have relationships defined as links, and then the stylesheet that prepares that data for delivery to the desktop turns those links into hyperlinks appropriate to the client program (in most cases today, a web browser) running on that desktop. It’s possible with XSLT today; like Ari, I’d love to see CSS allow this as well, although truly arbitrary conversions, such as the use of an element value to fill the href role, would be tougher with CSS than with XSLT. If CSS just allowed us to treat foo/@bar as a/@href, that would be great.
For another recent thread on what’s right and what’s wrong with XLink, see the thread beginning with Micah Dubinko’s XLink and mixed vocabulary design posting. See here and here on the threaded list page for links to later entries in the thread.
Instead of closing with the overly-discussed question (at least on xml-dev) “what do you think is wrong with XLink?” below, I decided to go with something inviting more constructive answers…
Is it worth it for the W3C to convene a Working Group to create an XLink 2.0, or maybe to christen a “profile” of 1.0 that strips out certain parts?