[This local archive copy is from the official and canonical URL, http://www.stg.brown.edu/~sjd/xlinkintro.html; please refer to the canonical source document if possible.]
XML Linking, formerly known as XLink and as XLL (the eXtensible Linking Language), is a work in progress of the Web Consortium. It is closely related to the XML Recommendation, but adds functionality for high-function hypertext and hypermedia. It is now an independent Working Group, but its projects were started under the main XML Working Group, and progressed to solid Working Drafts there before being handed off to the new XML Linking Working Group.
The work of this WG has two parts: XLink proper provide advanced linking capabilities such as multidirectional and external linking, while the separate XPointer spec provides a convenient and easily-understood way of describing locations in XML documents. XPointer is now a layer on top of XPath, a joint specification from the Linking and XSL working groups, that provides a common system for specification location that are entire nodes or lists of nodes; the XPointer layer provides for locating other data, such as general user selections, which are not whole nodes and correspond closely to the DOM "range" construct.
Either of XPointer and XLink can be used without the other; the most obvious example is that XLinks of course can connect many kinds of data besides XML (audio, video, VRML, program code, whatever); likewise XPointer can be used to specify locations regardless of whether those locations are formal link-ends. Yet they are especially valuable in combination, and of course in combination with XML itself.
XLink is edited by Steve DeRose. Eve Maler and Tim Bray have served as co-editors with me previously. The other co-editors are now: James Clark (XPath); Ron Daniel (XPointer); David Orchard and Ben Trafford (XLink).
Relevant documents can be found on the Web Consortium site.
XLink adds these kinds of advanced hypertext linking functionality to the Web (and other environments where it may be used):
Links that lead to multiple destinations.
Bi-directional links (note that "go back" is not at all the same thing: a bidirectional links can be traversed either direction regardless of whether you went the other way first.
Links that annotate read-only documents. That is, you can create links that will show up when people view a document even though you don't own the document. Of course, this involves a process of deciding whose links you do and don't want to view in this way; but this also makes it possible to build a valuable infrastructure of annotation, commentary, and communal evaluation and discussion on the Web. Ever wonder why the Web doesn't have sticky notes (barring a few exceptional exceptions)?
A standard way of attaching roles and descriptive titles to the various ends a link attaches, and asserting connections between particular ends.
Links with certain widely-neededd special behaviors, such as expand-in-place, new window vs. replacement, automatic follows, and so on. Although these behaviors can be programmed now with Java or other tools, providing the specific semantics means that the behaviors exist as first-class objects themselves, and can be processed in turn (which is not true of general computer programs). Full specifications still require a style language such as XSL, but for many common applications XLink's built-in behavior hints are likely to be enough (and provide an easy way to locate and change behaviors, short of analyzing arbitrary Java[script] code).
Link databases, with all the consequent possibilities for filtering, sorting, analyzing, and processing link collections.
XPointer provides better location specifications. It doesn't "return" things; it is simply an abstract language that specifies locations; obviously XLink can use it as part of specifying where its link-ends reside. Some added capabilities of XPointer (beyond HTML's rudimenary use of fragment identifiers on the end of URLs) include:
Links that point to specific places inside of documents, even when the author of those documents didn't already provide an ID at just the right place.
Fine-grained addressing to elements, other information objects, point and strings selections, and spans (also called ranges) inside documents.
A clear syntax for talking about locations and relationships in hierarchies (such as the structure of XML documents), so that locations are human-readable and writable, rather than mere hash.
XPointers are largely based on TEI extended pointers, a proven and multiply-implemented technology for the same purpose, developed by the Text Encoding Initiative.
XPointer builds on XPath, a joint specification of XSL and XML Linking. XPath provides generic pointing expressions that can locate any node or set of nodes in an XML document structure. It does so using combinations of various axes and predicates. In short, axes pick out a set of candidate nodes somehow related to a starting node (such as all its ancestors, siblings, children, descendants, attributes, etc), and predicates then pick from among those candidates.
What XPointer brings to the table beyond XPath, includes:
A way to encapsulate locator expressions inside URI fragment identifiers
A way to refer to the many locations that aren't nodes or sets of nodes, such as words, phrases, or other selections, that may even cross element boundaries.
A few special location methods needed to fully support hyperlinking.
See the W3C documents for more details, and to be sure your information is up to date.
Back to home page of Steve DeRose
or STG.
Or, contact me via email.