Menu

XLink: Who Cares?

March 13, 2002

Bob DuCharme

The question "who cares?" is usually a rhetorical question -- not a query for information, but a statement in question form that expresses something declarative. This rhetorical question usually means "I don't care and doubt if anyone does." When I say "XLink: who cares?", however, I don't mean it rhetorically. I really want to know: who out there still cares about XLink?

I did care, ever since I first heard about the work on "XML Part 2: Linking," as it was called at the announcement of XML's existence at SGML '96. (XSL, before XSLT was split away from XSL-FO, was Part 3). I got excited at the concept of linking that was more powerful than HTML's but easier to understand than HyTime's. I looked forward to the creation of out-of-line links that connected two, three, or more resources into a single link without requiring write access to those resources. I saw how the ability to define and assign link types would ease the end user's difficulty in navigating the growing amount of connected information on the Web. I thrilled to the talk of linkbases becoming a new category of information product to buy and sell, creating new information by making intelligent connections between existing information.

XLink is the only XML-related W3C specification that took over four years to get from first Working Draft to Recommendation status. Now that it's been a stable, finished spec for eight months, we're still seeing very little activity. So what's out there? Who cares about XLink?

Current Products and Projects

The W3C's XML Linking Implementations page, although it was last updated in December of 2000, still lists nearly all of the active XLink implementations out there -- and it only has seven entries.

The chart's columns show the basic features to look for in an XLink implementation. The first two columns list the two categories of links: simple links, which associate a single local resource to a single remote resource, and extended links, which can link multiple resources, all of which may be external to the document containing the link markup. This ability to provide "out-of-line" links, or links between arbitrary resources on the Web without requiring write access to those resources, was one of the most exciting promised features of XLink; the seven rows of the chart have two "yes" entries in this column, one "partial," one "N/A," one blank, and two "no" entries.

The remaining columns of the chart mostly describe various possible link semantics: whether each software project can implement the new/replace/embed values of the xlink:show attribute and the "onLoad" value of the xlink:actuate attribute (see Fabio Arciniegas's XLink Reference or a piece that I did for background on these two attributes), as well as columns to indicate support for linking of third-party resources and support for linkbases.

Fujitsu's XLiP

The only project with more than three "yes" entries in the table's eight columns is Fujitsu's XLiP, the "XLink Processor." Its XLink engine advertises support for XLink simple and extended links, including support for locator, resource, and arc elements. The engine itself isn't available, but Fujitsu offers two demos that you can download that use the engine. With the older demo (last modified September 5, 2000, and only supporting the Candidate Recommendation version of XLink), a Java-based browser lets you open up included sample files and display them in a tree. It displays tree nodes that can serve as the starting resource in an XLink traversal in red; selecting them and clicking the "Start Traversal" button either jumps the cursor to the appropriate node or displays a dialog box that offers a choice of actuate actions.

The other demo, made available last December, is a server-side XLink application requiring the Tomcat web server and some additional Java libraries to run. A web page of screenshots show how it displays XBRL balance sheets and lets you follow XLink-based links on balance sheet entries.

A team at Fujitsu continues to work on XLiP but have no plans to release it outside of Japan, so we can't count on it to contribute much to XLink's popularity in the rest of the world.

xlinkit and RDDL

xlinkit, according to its home page, is a "lightweight application service that provides rule-based link generation and checks the consistency of distributed documents, databases and web content." It evolved out of research on distributed software engineering at University College, London, and the transition from university research project to commercial software offering is currently underway. xlinkit evaluates a set of distributed resources such as XML documents and databases against a set of user-specified rules and generates a set of XLink links that identify consistent and inconsistent data relationships according to those rules. xlinkit doesn't use any XLink semantics, so the task of identifying sets of resources whose data are inconsistent according to a set of defined rules could probably be done just as well using any markup that collected URLs into groups and added additional information to each group -- for example, RDF.

The xlinkit folks also have a free XLink extended link processor called XTooX that reads a document with extended links, reads in any resources referenced by those links, and creates new versions of those resources with the links incorporated into them.

RDDL, an effort to put something usable at the address referenced by a namespace URL, uses XLink syntax to specify the relationship between the URL and other resources. (See RDDL Me This: What Does a Namespace URL Locate? by Elliotte Rusty Harold for a good introduction.) RDDL is a specification, not a product or a program; like xlinkit it uses XLink to identify resource relationships. It goes beyond xlinkit's use of XLink (in fact, beyond any project's use) by using the xlink:role and xlink:arcrole attributes to describe the nature and purpose of the related resources. This use of XLink semantics plants RDDL a little more firmly in XLink territory than xlinkit. In its own words the RDDL spec "has no official standing and has not been considered nor approved by any organization," but as a well thought-out approach to a real problem that uses XLink to address that problem, it's a nice example of XLink use. Apart from xlinkit, it's a pretty lonely example.

Browsers

The currently available release of Mozilla, the open source basis for recent releases of Netscape Navigator, implements simple links with xlink:show value of "new" or "replace" but not "embed" and an xlink:actuate value of "onLoad" or "onRequest". You can see this support in Netscape Navigator 6.2 as well if you take either browser to a test page that I put together. Mozilla and Navigator have no support for extended links, and none seems to be planned.

Neither Internet Explorer 6.0 nor Opera 6.01 have any of the simple XLink support shown by Mozilla. (It is possible to impose some XLink simple link support on Opera using undocumented CSS tricks described by Simon St. Laurent in an April 2000 XML.com article XML Web Pages with Opera 4.0.) A search on microsoft.com for pages that mention both Internet Explorer and XLink revealed no hints about eventual support. A similar search at opera.com revealed nothing about planned XLink support for the Opera browser.

DocZilla, a Mozilla-based browser from the Finnish company CiTEC, is the only product not listed on the W3C's "XML Linking Implementations" page that I could find with any degree of XLink support. DocZilla adds to Mozilla's support of simple links with some skeletal support, still in the beta stage, for extended links. (Like Mozilla, they have no support for embedded links planned.) You can play with DocZilla's support for extended links by taking an evaluation copy of DocZilla 1.0 to its fire test page. CiTEC offers no other documentation or demonstrations of extended link support; even this single demo page is apparently not widely known within CiTEC.

X2X

X2X is a link manager from empolis, a software and services company based in Germany, and it can import and export extended links. By using a relational database as its core engine, X2X can scale up to a large number of links with no loss of speed. X2X version 2 was released last June, and it looks like a very powerful product -- extensive documentation is available from the product's home page -- but at £25,000 for an intranet license and £50,000 for an Internet license, it's not priced to become the widely-used killer app that will gain XLink a footing in a large number of XML systems.

4XLink

4Suite is an open source collection of Python tools for XML processing. Its 4XLink module provides a bit of XLink support by processing XLink links with an xlink:actuate value of "onLoad" and xlink:show values of "embed" or "replace". As a document processing system, and not an end-user GUI tool, it couldn't be expected to implement an xlink:actuate value of "onRequest" or an xlink:show value of "new" -- new what? -- so full support of the XLink spec wouldn't be something to look for here. 4Suite's change log file lists "Introduced 4XLink: A processor to expand XLink attributes" as a November 1, 2000 entry and doesn't mention XLink since, so this too doesn't look like a source of much recent XLink activity. (4Suite also includes 4RDF, an RDF library. Uche Ogbuji, one of the key people behind 4Suite, has been a very active proponent of RDF of late.)

Conferences, XML Press, and XML Websites

At last December's XML Conference and Exposition 2001, only one presentation besides my own mentioned XLink in its title. At the same conference the previous year in Washington D.C., only two presentation titles mentioned XLink. At the Extreme 2000 conference in Montreal, one tutorial covered XLink and one presentation mentioned XLink in its abstract; at the same conference last year, none of the tutorials or presentations mention XLink or even linking. (Four, on the other hand, mentioned RDF, and nine mentioned Topic Maps.)

The most complete source of XML-related news is Robin Cover's news pages at the OASIS-sponsored XML Cover Pages. Since the story about the W3C's promotion of XLink to Recommendation status in June of 2001, it hasn't had a single story about XLink. The only other Cover Page news story about XLink was the announcement of X2X in February of 2000, over a year earlier. Before that, there are no stories about W3 XLink as far back as January of 1999, when Robin's archive of XML news begins.

The other key source of day-to-day XML news is xmlhack.com. Since December of 1999, seven of the twenty mentions of XLink in xmlhack.com story headlines were for stories announcing XLink's progress from W3C Note to W3C Recommendation. Of the remaining stories, the most recent was a November 2000 story about the addition of 4XLink to 4Suite. Since then, there's been no news about XLink outside of the XLink spec's progress.

How about XLink coverage in the feature article XML press? Let's start with XML.com. Not counting the Resource Guide or Buyer's Guide references to XLink resources outside of XML.com, this publication has run the following stories about XLink since it began publishing: a three-part article by Fabio Arciniegas in September of 2000; a description of an application using SVG, XSLT, and XLink by Didier Martin in March of that year; a February 2000 description by Edd Dumbill of an XLink tutorial given by Eve Maler at XTech 2000; an article that I wrote about the value of out-of-line links in July of 1998; and the month before that, an introduction to XML Linking by Eve. That makes five articles in XML.com's history, with the last one published 17 months ago.

A search through the archives of IBM developerWorks, a site with a large amount of useful XML articles and resources, only shows two articles whose titles mention XLink. Searching the archives of the XML Journal for "XLink" gets hits on twelve articles, none of which mention XLink in their titles. XML Magazine, since their premier issue in 1999, has run one article mentioning XLink in its title and no other articles mentioning XLink in their titles or abstracts.

A valuable web site for gauging XML software development activity is xmlsoftware.com. Not counting the entry for consistencycheck.com, which was renamed to xlinkit.com, their page on XLink and XPointer software has only eight entries that mention XLink. Of those not mentioned elsewhere in this article, one was someone's student project in early 1999 and the rest are from 1998. A search for "xlink" at Open Source Development Network, which lets you search across SourceForge.net, Slashdot, freshmeat, Linux.com, and other sources of open software and news, only turned up 4Suite and some hits unrelated to the W3C's XLink such as "ZxLink" and "Linuxlinks.com." There is clearly very little XLink software out there to work with.

Why So Little Attention?

To address this question, let's split up the simple link and extended link cases, because they're geared to such different roles in an application. Simple links are explicitly presentation-oriented, while the presentation aspects of extended links are still a mystery to most of us.

Simple Links: Cleaner and Less Supported than the Alternative

The XLink Recommendation takes pains to not limit itself to describing link semantics in terms of web browsers on a computer screen. For example, Section 5.6.1 tells us that an xlink:show value of "new" "should load [the ending resource] in a new window, frame, pane, or other relevant presentation context." It doesn't need to be in a new window, frame, or pane; a voice recognition browsing system that you operate from your car could...well, I'm not holding my breath on someone figuring that one out and then implementing it. The few XLink applications as far as the eye can see that implement an xlink:show value of "new" do so by displaying the ending resource in a new window.

What About XPointer?

Perhaps because of their common roots in HyTime, XPointer and XLink have often been lumped together. They do complement each other well, but I chose to concentrate on XLink for this article because if XLink simple and extended links play different roles in an application, XPointer, a separate spec, plays a very different role. While the use of XPointer adds a great deal to the granularity of how XLink links address resources, XLink links that use no XPointer syntax to address resources could still be very useful if there was any large-scale use of them.

Politically, the lumping together of XPointer with XLink could be seen as one of the causes of XLink's slow progress to Recommendation status, but eight months after that journey has completed, XLink has stood on its own long enough that we can't blame XPointer for XLink's problems.

Mozilla and DocZilla do deserve credit for the number of XLink simple link xlink:show/xlink:actuate combinations they support, but with the same effects available in a wider variety of browsers (including the eight hundred pound gorilla's browser, Internet Explorer) using a combination of HTML and JavaScript, there's still no good reason for people to use XLink simple links.

During the four years it took for XLink to become a Recommendation, we could blame the lack of software on its moving target status, but we can't do that anymore. (And, think of the XML-related technologies that didn't need to wait for their Recommendations to see interesting, useful applications -- XSLT, SVG, and XSL-FO are the first to come to mind). Why aren't new XLink implementations coming along?

Software development in an entirely new area doesn't come out of a void. There must be a community of interested people being enthusiastic and giving talks and publishing articles to evangelize the technology. No one seems excited enough about XLink to be doing this anymore, and interest is dying away. I used to be excited about XLink, and did my share of articles and conference talks, but now the half-full glass is looking half-empty to me, and its contents seem to be evaporating. I hope that I'm wrong, and that people point out lots of great XLink developments in this century that I've missed, but as with my wait for the voice-activated hyperlinked browser in my car, I'm not holding my breath.

Perhaps the interest isn't dying away, but was merely shifted to RDF and Topic Maps, technologies that seem to be fulfilling much of the promise of XLink. Perhaps their success represents the triumph of the original ideas of XLink, with out-of-line links and linkbases finding success under different names. This would put a positive spin on the history of XLink, but I'm losing hope on seeing any large-scale use of the elements described in the XLink Recommendation.

By describing resource traversal in terms of the ending resource displaying in a new window or the same window, and in terms of when it does so, the link semantics are framed in a way that can be implemented on multiple systems, so it has some of the portability and longer shelf life advantages of markup that is not presentation-oriented. But it's still about how the resources are presented to the user and is, therefore, not markup that you'd store in your core XML database or document collection that you use to generate other formats as needed. Your elements that reference footnotes would store the ID information necessary to find the right footnotes, and your news stories, legal briefs, and judges' decisions that reference legal statues would store the ID information necessary to find those. If you decided that the footnotes or legal statutes should appear in a new window, you'd have a stylesheet add the appropriate XLink markup to the version of the markup being sent to the browser -- if the browser knew what to do with XLink markup.

Netscape, one of the two big mainstream browsers, is based on Mozilla, so it does know what to do with xlink:actuate values of "onLoad" or "onRequest" and xlink:show values of "new" and "replace" but not "embed". The other big mainstream browser, as we saw earlier, doesn't. Internet Explorer and Netscape do both support the same bits of JavaScript and HTML trickery necessary to give you the same effects as XLink simple links' onLoad/new, onLoad/replace, onRequest/new, and onRequest/replace combinations. If web developers now have this available using syntax that works on both IE and Netscape, why would they switch to to a syntax that only works with the less popular of the two? From an engineering standpoint, the XLink way is simpler and cleaner; from a practical standpoint, it offers no obvious advantages, and it takes practical advantage for people to get behind a new technology.

Extended links don't have much place in a browser unless the browser turns out-of-line links into in-line links in a special document created for this purpose. So where would one look for extended link support?

Extended Links: No Troops to Fight the RDF and Topic Map Armies

A linkbase of out-of-line links as an intermediary between resources that use markup customized for their semantics (for example, legal commentary using footnote and statute elements) and output devices using their own specialized markup (for example, web browsers using HTML) could identify relationships between those resources and provide a platform for presenting those relationships using whatever interface widgets are available on the output devices. If someone wanted to build such a system today, what would they use? Probably RDF or Topic Maps.

XLink, RDF, and Topic Maps have different core purposes. However, if you think in terms of the Entity Relationship Model (a data modeling system that, since the 1970s, has provided developers of many different methodologies a way to model both entities and entity relationships by designating attributes for both), the key strength of these three technologies is their ease at identifying relationships between remote resources and letting you assign attributes to those relationships, making the relationships easier to navigate and manipulate. In the general case of doing this, RDF is getting more popular -- steadily, if not quickly -- as a way to add arbitrary information, especially metadata, to resources that developers can't edit themselves. Many developers are turning to the growing number of RDF tools to identify and take advantage of relationships between existing resources. For example, the W3C's Annotea project, which lets you create web page annotations, uses RDF, although XLink could have served the same purpose.

For a more specific case of the potential value of linkbases, why don't people use XLink to collect a group of related links that draw connections between otherwise disparate information and then use this collection to impose a new view on the information, like an index? Because they're using Topic Maps. The attention given to Topic Maps at XML conferences is almost exasperating at times, but this attention is evidence of a community of believers working hard to give talks, write articles, and develop and demonstrate software that illustrates how Topic Maps are now solving problems that XLink linkbases once planned on solving.

The lack of a comparable community for XLink is the most telling symptom of its lack of momentum. While some leap into the Topic Maps vs. RDF debates and others sit back and smirk at the "but you can do all that with this" arguments made by both sides, no one is out there making these arguments for XLink.

Not Much Ahead

Let's review the availability of XLink support in the products that implement more than a small subset it:

  • Fujitsu has no plans to make XLiP available outside of Japan.
  • X2X is priced to only be used by large, well-funded companies.
  • DocZilla's superset of Mozilla's XLink support (that is, their support for extended links) has no documentation outside of marketing literature claims and no coherent demonstrations of how their extended links work.

Mozilla and DocZilla do deserve credit for the number of XLink simple link xlink:show/xlink:actuate combinations that they support, but with the same effects available in a wider variety of browsers (including the eight hundred pound gorilla's browser, Internet Explorer) using a combination of HTML and JavaScript, there's still no good reason for people to use XLink simple links.

During the four years it took for XLink to become a Recommendation, we could blame the lack of software on its moving target status, but we can't do that anymore (and think of the XML-related technologies that didn't need to wait for the Recommendation to see interesting, useful applicationsk, but I'm losing hope on seeing any large-scale use of the elements described in the XLink Recommendation.

Software development in an entirely new area doesn't come out of a void. There must be a community of interested people getting psyched and giving talks and publishing articles to evangelize the technology. No one seems excited enough about XLink to be doing this anymore, and interest is dying away. I used to be excited about XLink, and did my share of articles and conference talks, but now the half-full glass is looking half-empty to me, and its contents seem to be evaporating. I hope that I'm wrong, and that people point out lots of great XLink developments in this century that I've missed, but as with my wait for the voice-activated hyperlinked browser in my car, I'm not holding my breath.

Perhaps the interest isn't dying away, but was merely shifted to RDF and Topic Maps, technologies that seem to be fulfilling much of the promise of XLink. Maybe their success represents the triumph of the original ideas of XLink, with out-of-line links and linkbases finding success under different names. This would put a positive spin on the history of XLink, but I'm losing hope on seeing any large-scale use of the elements described in the XLink Recommendation.