In the Halcyon days of the early XML effort, just three TLAs sufficed to map out the territory. XML itself, of course, was first born. From there, the idea was that birth would be given to XLL (XML Linking Language) and then XSL (eXtensible Style Language).

The theory was that just as XML resulted from subsetting SGML (ISO 8879), an XML linking language and an XML styling language would follow from the subsetting of the HyTime (ISO/IEC 10744:1992) and DSSSL standards (ISO/IEC 10179:1996) respectively.

Somewhere along the line -- I cannot recall where or why -- XLL changed its name to XLink. Anyway, I wrote an article about it back in 1998 for Dr Dobbs Journal: "XLink: The XML Linking Language". Looking back at the article now, I would give myself ten out of ten for enthusiasm and zero out of ten for foresight.

The introduction to the article says, "(XLink) is a draft proposal from the World Wide Web consortium that addresses the shortcomings of HTML's simple hypertext model and allows the rich structure of XML documents to be fully utilized in hypertext creation and management."

Although Version 1.0 of XLink became a W3C Recommendation in June of 2001[1], it has not exactly taken the world by storm. One reason for this is that users are remarkable tolerant of the shortcomings in the hypertext model of HTML. Although the functionality enshrined in Xlink looks very appealing (multi-node links, link metadata, out-of-line linking, two way link traversal and so on.) it seems that users -- and thus developers -- have voted with their feet and walked away.

I have a theory as to why this is so. The problem of linking things together on the Web takes an almost vertical ascent into complexity which layer of abstraction piling on layer of abstraction very quickly.

All you need to do is move slightly beyond the "link this to this" model of HTML and you are in deeply complex philosophical territory. If you doubt that this is the case, I would suggest you take a look at the HyTime standard. The sheer size and complexity of it amply demonstrates the enormity of problem hidden behind the simple term "linking".

Adding to the woes of XLink is the fact that there are other fields of XML endeavor that overlap in scope with the linking problem. Perhaps first out of the blocks was the XML namespace recommendation, which, after much debate, eschewed the fundamental HyTime lore known as Architectural Forms[2]. Then DTDs -- on which XLink is based -- began to fall out of favor. Somewhere along the line the Opera web browser shipped with a mechanism for creating links that used CSS syntax to create links instead of XLink. Topic Maps, RDF, and the Semantic Web addressed the linking problem from different perspectives. All over the map, efforts that required smart linking capabilities have sprung up that do their own thing rather than adopt or extend XLink.

It is now about five years since I thought XML linking would be an established part of the Web infrastructure right after XML. So much for that plan. Is XLink dead in the water? I don't think so. But, as in so many other areas of technology, the killer application will not be in the space originally envisaged.

Simply put, I believe that clever linking technology will be an important part of Web Services technology -- not browser technology.

Think of it this way. You are using a web browser. You click a link, you get back a HTTP error 404 -- big deal. As I said earlier, users have shown themselves to be incredibly forgiving of broken links.

Now switch from being a user to being a business process. You invoke a web service by "following a link" in code. You get back a 404. Do you care? Darned right you do! This is process-to-process communications -- not human to process. Humans are tolerant of duff links -- processes are not. Bad things will likely happen if a link goes south in the middle of a Web Service choreography.

Enterprise class Web Services, Service Oriented Architectures, call it what you will -- this is where there is the biggest need for robust, flexibly linking on the Web. I look forward to seeing what solutions emerge. Regardless of the answer proposed, I'm pretty sure it is already in the HyTime standard somewhere!

NOTES

[1] http://www.w3.org/2001/06/link-base-pressrelease [2] http://www.jclark.com/sp/archform.htm