XML.com: XLink: Who Cares?

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.

What's your viewpoint on XLink? Will its time come, or should it be left in the past? Share your opinions in our forum.
(* You must be a member of XML.com to use this feature.)
Comment on this Article

Titles Only

Newest First

XBRL ..the big XLink user
2004-06-24 07:10:29 RichSC [Reply]

You're right about there not being anything..still! But XLink is integral to XBRL, the financial reporting standard, which we are working with. This would seem to be some update to this, but I'm not having much luck finding anyone out there doing any XLink work other than the XBRL consortium, of which Fujitsu is a large part. Any updates?>
- XBRL ..the big XLink user
  2004-06-24 08:54:52 Bob DuCharme [Reply]
  
  See Tony Coates' comment below. XBRL continues to be the most significant user of anything in XLink beyond the very simple features.

i SO care about XLINK...
2003-02-14 09:31:33 ilya lehrman [Reply]

I've got this great idea the hinges on XLink functionality... now just looking for the way to implement it and finding *surprise!* that there's so little support from technology vendors (Microsoft, etc.)! that's a shame - the potential benefits of xlink are tremendous, but i guess i'll have to implement the ... implementation mechanism myself.

oh well.

cheers!

Xlink and ebooks
2002-05-20 14:00:05 Jean-Baptiste de Vathaire [Reply]

One of the reasons for the current lack of success of XLink is perhaps the difficulty to develop intertextual applications in an open and fluctuant environment like the web. As each resource can be at any moment modified or removed, an intertextual link can become quickly obsolete. That is the reason why in Xanadu, the project of Th. Nelson, ressources are clearly identified and never disappear: it is the only way to develop a real intertextualy. As the web doesn't work like that, it is condemned to stay somehow a justaposition of texts.
I'm doing a PhD on "transtextuality on eBooks for human sciences publishing", and I'm trying to experiment the use of XLink on eBooks, because I believe that some functionalities that XLink makes possible are well adapted on this closed environment.

XML Topic Maps uses XLink Simple Links
2002-03-22 09:29:55 David Steinberg [Reply]

see
XML Topic Maps (XTM) 1.0
TopicMaps.Org Specification (http://www.topicmaps.org/xtm/1.0/)

and

ISO/IEC JTC 1/SC34
Information Technology --
Document Description and Processing Languages
http://www.y12.doe.gov/sgml/sc34/document/0277.htm

"The HyTime-based meta-DTD uses HyTime varlinks, while the XTM DTD uses "simple" Xlinks"

David Steinberg
ottawa canada

missing pieces
2002-03-18 23:17:14 Erik Wilde [Reply]

hello. in my opinion, one of the most important reasons for the lack of success of xlink are the missing pieces. in the same way as xml lacked a proper data model before the infoset came along, we also need an xlink infoset. the w3c note on xlink and styling has made a frist attempt, but it has holes. until there is no formal definition of the xlink infoset, it will be hard to reasonably define things such as xlink transformation, linkbase accesses, queries into the linking structure and similar things. i guess we can learn from history here, which has shown that as soon as you want to do non-trivial things with xml (such as xslt or xquery), it is absolutely necessary to have a data model.

another thing is that software companies will not really push things like xlink, which basically is about an open web. when you look at microsoft's smart tags, you can see that what they are doing is nothing more than generic linking under the control of microsoft, which is much more in their interest than general xlink support. general xlink support in browsers (given a suitable linkbase access method) would enable generic linking on the web for everyone.
- missing pieces
  2002-03-19 22:00:17 Adrian Edwards [Reply]
  
  Not sure that lack of a data model is the real reason behind the icy community response. The HyTime standard (ISO/IEC 10744:1992), which included linking formalisms for SGML that parallel XLink's for XML, added a very rigorous data model known as the �grove paradigm� [1] with its Second Edition (ISO/IEC 10744:1997), yet has suffered a similar (and similarly undeserving IMHO) fate. Perhaps we need to look elsewhere to identify why XLink has not caught on.
  
  I believe that the most significant contributing factor in XLink's stagnation is the lack of an evangelical core community that Bob rightly highlights in his article. Is it a coincidence that the most recently updated page on the http://www.hytime.org site that Bob links is 31 August 1999? No. The key intellectual figures in generalised hypertext markup in the nineties: Newcomb, Kimber, DeRose, Prescod and Biezunski, celebrated the new millennium by forming their own consulting companies and abandoning HyTime and XLink on the speaking circuit. Those most capable of playing the role for XLink that say
  
  It is also no coincidence that these figures (Newcomb and Biezunski in particular) are now largely responsible for the "almost exasperating" current level of exposure for Topic Maps at industry conferences. Where would XLink be if the same energy and experience were brought to bear evangelising its virtues? Perhaps in no better position than HyTime, although the relative simplicity of XLink does give one some hope that it could appeal to the mass market, given the right publicity.
  
  Perhaps however, as admitted in XLink�s own 'Design Principles' [2] "... certain functionality, in particular out-of-line link handling with extended document groups, is inherently difficult."
  
  [1] http://www.prescod.net/groves/shorttut/
  [3] http://www.w3.org/TR/NOTE-xlink-principles#1.9

Promoting the use of XLink
2002-03-18 12:23:38 David Lowe [Reply]

Excuse the rather shameless plug, but for those of you interested in learning more about XLink and XPointer, including the benefits that it can bring and how it can practically be used within the current Web environment (including dealing with the lack of effective XLink implementations) you might like to look at our soon to be released book (currently with the publishers): Wilde, Erik; Lowe, David (2002), "XPath, XLink, XPointer and XML: A Practical Guide to Web Hyperlinking and Transclusion", Addison-Wesley Longman.

XBRL v2 @ xbrl.org
2002-03-18 02:55:08 Anthony Coates [Reply]

XBRL (Extensible Business Reporting Language) version 2 using XLink linkbases heavily, as a way of providing multiple views and annotations of the same underlying business numbers. XBRL is big enough to drive XLink tool development all by itself (see http://www.xbrl.org/ for details).

Cheers,
Tony========
Anthony B. Coates
XML Architect
Chief Technology Office
Reuters Plc, London.
Tony.Coates@reuters.com
========
- XBRL v2 @ xbrl.org
  2002-03-22 09:09:12 David Steinberg [Reply]
  
  I would be really interested in Bob's reaction to this interesting comment.
  
  David Steinberg
  ottawa
  Canada

I guess IBM does
2002-03-16 19:12:58 Phil Young [Reply]

I'm studying for their XML 141 test ( so I can get a job in the Bay Area). IBM wants me to know XLink for their test, but it seems very impractical considering very few use it. This is especially true for a certification test.

I think XLink sounds like a great idea, a little vague maybe, and examples of its use always seem forced. If there were support for it in browsers I could see how it would be very useful.

What I'm wasting my time on Xlink and the IBM certification given the state of affairs in the software creativity and application industry around here I don't know though.

Thanks for the article.

SVG uses XLink Simple Links
2002-03-16 13:26:18 Chris Lilley [Reply]

SVG uses XLink Simple Links, so all SVG rendering implementations are also XLink Simple Link implementations. For example Adobe, Amaya, Batik, Bitflash, CSIRO, Ionic, JaMaPS, Mozilla, XSmiles.

http://www.w3.org/Graphics/SVG/SVG-Implementations.htm8#viewer

Difficulties styling XLinks
2002-03-16 01:19:10 Bob Stayton [Reply]

What's a stylesheet to do with an XLink? Turns out that isn't a trivial question, and it is holding back the implementation of XLinks. For a thorough discussion of this problem, see the W3C Note on XML Linking and Style edited by Norm Walsh, at http://www.w3.org/TR/2001/NOTE-xml-link-style-20010605/
- Difficulties styling XLinks
  2002-03-16 13:30:19 Chris Lilley [Reply]
  
  This issue is not styling, but transformation. If the model of linking is to take a document with links and make a derived document 'without' links, then sure, there is a problem adresssing that derived document or linking to it. After all, it doesn't have a URL. But that is a general problem with in-place transformation - anonymous generated resources.
  
  But for styling links, there is no particular problem. For example, Opera has some CSS extensions that let it do styling of XLinks, and of links in WAP content, and in Open eBook. SVG rendererd regularly style XLinks in SVG content.
  - Difficulties styling XLinks
    2002-03-19 08:12:59 Erik Wilde [Reply]
    
    i disagree with the opinion that xlink styling is not a problem. opera's css extensions are interesting, and xsl-fo also has some (rather weak) support for styling links. but: if you think of the linking model of xlink, you will see that many complex links (such as multi-ended links or transclusions and the whole issue of how to style titles and roles) have no well-defined representation. i think that this is one of the reasons why xlink support generally is so weak. implementors must solve many problems that are not part of xlink (and rightly so), but which should be specified in additional specs making it clear how complex xlinks should be styled. currently, even if browsers were supporting xlink, they would display them in very different (and proprietary, as indicated by opera's css extensions) ways.

Glad You Asked . . .
2002-03-15 18:08:34 Tom Poe [Reply]

Hi: First, the comment, then I read the article. What do you think about that?

XLink was one of the most exciting concepts I have ever come across. In 1998, I put up this:
http://www.worldccr.org/xmloriginal.htm in anticipation of the next generation of Internet!

Boy, was I wrong! You know, if XLink was developed as originally envisioned, P2P, copyright issues, e-commerce, and all the rest of the enormous problems we are facing, today, would have been far different. My feeling, and maybe your article will shed light on it, is that M$ and the other "sponsors" shelved this remarkable potential, because they knew what tremendous empowerment it would bring to the undeveloped nations seeking to level the Internet playing field. Now, on to reading your article.
Thanks,
Tom Poe
Reno, NV
tompoe@renonevada.net

A Business Case Has Been Made
2002-03-15 16:20:12 Ben Dean [Reply]

Take a look at the Social Security Administration's 16 Jan 2002 presentation to the Federal CIO Council XML Working Group found at XML.GOV.

xlink hunger
2002-03-15 02:45:55 bryan rasmussen [Reply]

my xlink hunger lasted approximately 6 months after first reading about it, which would be two-three years ago now I guess, dodgy arithmetic I'm sure but I can't be arsed looking at a calendar and trying to figure it all out.
after that the world weary cynicism set in, one of the things that gets my goat is how many books, present day ones mind, genuflect at the altar of xlink, xpointer, Xinclude and the like, of course I don't buy many xml books anymore but I do look at them in the bookstore; has anyone else noticed this padding of content?