XLinks are an attribute-based syntax for attaching links to XML documents. XLinks can be simple Point A-to-Point B links, like the links you're accustomed to from HTML's A element. XLinks can also be bidirectional, linking two documents in both directions so you can go from A to B or B to A. XLinks can even be multidirectional, presenting many different paths between any number of XML documents. The documents don't have to be XML documents--XLinks can be placed in an XML document that lists connections between other documents that may or may not be XML documents themselves. Web graffiti artists take note: these third-party links let you attach links to pages you don't even control, like the home page of the New York Times or the C.I.A. At its core XLink is nothing more and nothing less than an XML syntax for describing directed graphs, in which the vertices are documents at particular URIs and the edges are the links between the documents. What you put in that graph is up to you.
Current web browsers at most support simple XLinks that do little more than duplicate the functionality of HTML's A element. Many browsers don't support XLinks at all. However, custom applications may do a lot more. Since XLinks are so powerful, it shouldn't come as a surprise that they can do more than blue underlined links on web pages. XLinks can describe tables of contents or indexes. They can connect textual emendations to the text they describe. They can indicate possible paths through online courses or virtual worlds. Different applications will interpret different sets of XLinks differently. Just as no one browser really understands the semantics of all the various XML applications, so too no one program can process all collections of XLinks.
A simple link defines a one-way connection between two resources. The source or starting resource of the connection is the link element itself. The target or ending resource of the connection is identified by a Uniform Resource Identifier (URI). The link goes from the starting resource to the ending resource. The starting resource is always an XML element. The ending resource may be an XML document, a particular element in an XML document, a group of elements in an XML document, a span of text in an XML document, or something that isn't a part of an XML document, such as an MPEG movie or a PDF file. The URI may be something other than a URL, for instance a book ISBN number like urn:isbn:1565922247.
A simple XLink is encoded in an XML document as an element of arbitrary type that has an xlink:type attribute with the value simple and an xlink:href attribute whose value is the URI of the link target. The xlink prefix must be mapped to the http://www.w3.org/1999/xlink namespace URI. As usual, the prefix can change as long as the URI stays the same. For example, suppose this novel element appears in a list of children's literature and we want to link it to the actual text of the novel available from the URL ftp://archive.org/pub/etext/etext93/wizoz10.txt.
<novel> <title>The Wonderful Wizard of Oz</title> <author>L. Frank Baum</author> <year>1900</year> </novel>
We give the novel element an xlink:type attribute with the value simple, an xlink:href attribute that contains the URL to which we're linking, and an xmlns:xlink attribute that associates the prefix xlink with the namespace URI http://www.w3.org/1999/xlink. The result is this:
<novel xmlns:xlink= "http://www.w3.org/1999/xlink" xlink:type = "simple" xlink:href = "ftp://archive.org/pub/etext/etext93/wizoz10.txt"> <title>The Wonderful Wizard of Oz</title> <author>L. Frank Baum</author> <year>1900</year> </novel>
This establishes a simple link from this novel element to the plain text file found at ftp://archive.org/pub/etext/etext93/wizoz10.txt. Browsers are free to interpret this link as they like. However, the most natural interpretation, and the one implemented by the few browsers that do support simple XLinks, is to make this a blue underlined phrase the user can click on to replace the current page with the file being linked to. Other schemes are possible however.
XLinks are fully namespace aware. The xlink prefix is customary, though it can be changed. However, it must be mapped to the URI http://www.w3.org/1999/xlink. This can be done on the XLink element itself, as in this novel example, or it can be done on any ancestor of that element up to and including the root element of the document. Future examples in this and the next chapter use the xlink prefix exclusively and assume that this prefix has been properly declared on some ancestor element.
Every XLink element must have an xlink:type attribute telling you what kind of link (or part of a link) it is. This attribute has six possible values:
Simple
Extended
Locator
Arc
Title
Resource
Simple XLinks are the only ones that are really similar to HTML links. The remaining five kinds of XLink elements will be discussed in later sections.
The xlink:href attribute identifies the resource being linked to. It always contains a URI. Both relative and absolute URLs can be used, as they are in HTML links. However, the URI need not be a URL. For example, this link identifies but does not locate the print edition of The Wonderful Wizard of Oz with the ISBN number 0688069444:
<novel xmlns:xlink= "http://www.w3.org/1999/xlink" xlink:type = "simple" xlink:href = "urn:isbn:0688069444"> <title>The Wonderful Wizard of Oz</title> <author>L. Frank Baum</author> <year>1900</year> </novel>
Copyright © 2002 O'Reilly & Associates. All rights reserved.