XLink: Who Cares?
by Bob DuCharme
|
Pages: 1, 2
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.
- XBRL ..the big XLink user
2004-06-24 07:10:29 RichSC - XBRL ..the big XLink user
2004-06-24 08:54:52 Bob DuCharme - i SO care about XLINK...
2003-02-14 09:31:33 ilya lehrman - Xlink and ebooks
2002-05-20 14:00:05 Jean-Baptiste de Vathaire - XML Topic Maps uses XLink Simple Links
2002-03-22 09:29:55 David Steinberg - missing pieces
2002-03-18 23:17:14 Erik Wilde - missing pieces
2002-03-19 22:00:17 Adrian Edwards - Promoting the use of XLink
2002-03-18 12:23:38 David Lowe - XBRL v2 @ xbrl.org
2002-03-18 02:55:08 Anthony Coates - XBRL v2 @ xbrl.org
2002-03-22 09:09:12 David Steinberg - I guess IBM does
2002-03-16 19:12:58 Phil Young - SVG uses XLink Simple Links
2002-03-16 13:26:18 Chris Lilley - Difficulties styling XLinks
2002-03-16 01:19:10 Bob Stayton - Difficulties styling XLinks
2002-03-16 13:30:19 Chris Lilley - Difficulties styling XLinks
2002-03-19 08:12:59 Erik Wilde - Glad You Asked . . .
2002-03-15 18:08:34 Tom Poe - A Business Case Has Been Made
2002-03-15 16:20:12 Ben Dean - xlink hunger
2002-03-15 02:45:55 bryan rasmussen
