You already know how to link XML documents together with XLink, and isolate specific nodes or node collections with XPath. Now uncover the third and final piece of the XML linking jigsaw - XPointer, an experimental technology from the W3C, which allows you to create XML links to specific points or ranges within an XML document.
So that takes care of XPath - but where does XPointer fit in?
According to the XPointer specification, XPointer serves as the basis for "fragment identifiers" in XLinks. You probably don't know this, but you use fragment identifiers pretty frequently in your daily Web development activities, to link to specific segments of an HTML document - they're the bits following the hash (#) symbol in a standard anchor tag. For example, in the hyperlink
<a href="http://www.paint.server/colors.html#tangerine">See what tangerine
would be a fragment identifier.
Just as fragment identifiers, when attached to an HTML hyperlink, direct the browser to a specific section of an HTML document, XPointers, when attached to an XLink, identify a specific location (or set of locations) within an XML document. This location could be a single character, a text string, a block of contiguous content, or a collection of elements; XPointer allows link authors to specify the location using XPath's built-in functions and conditional tests.
Let's take a quick example. Consider the following XML document, which I'll call "movie.xml":
<movie id="67" genre="sci-fi">
Jackman, Patrick Stewart and Ian McKellen</cast>
Here's a simple XLink, which uses an XPointer to link to the data for "X-Men"
using the movie's "id" attribute:
As you can see, XPointer, with the able assistance of XPath's location paths,
is used to create the fragment identifier that identifies a particular section of the XML data. Without XPointer, link authors would merely be able to reference XML documents; they would have no way of drilling down to specific points within those documents.
As the example above demonstrates, the syntax for an XPointer is usually
In order to offer link authors the flexibility to use "fallback links" - say,
if the document structure or content changes - the XPointer specification allows for more than one XPointer to be specified simultaneously. For example, [code] xpointer(id('67')/cast) xpointer(id('67')/director)
The XPointers are evaluated in left-to-right order, and the first successful evaluation is used.
The XPointer specification also defines two additional "shortcut" forms. The first of these is the so-called "bare name" form, which has been included primarily to maintain compatibility with the existing HTML fragment identifier. An XPointer of this form merely specifies a name, and refers to any element within the document which has an "id" attribute matching that name. Which means that I could write the XPointer above
and the two would still be equivalent.
An XPointer may also consist of a "child sequence" - essentially, a series of steps beginning with the document element and drilling down from there to the required resource. Note that the steps are defined in terms of integers, not element names - this XPointer references the first child element of the document element (the movie title.)
Bare names and child sequences may be combined together if desired.
As with XPath, you can use predicates and conditional tests to filter out unwanted nodes, and select from a variety of built-in function to further classify the result nodeset. I'm not going to spend any more time on this, though - instead, I'd like to concentrate on XPointer's extensions to XPath, which are primarily in the form of additional constructs to define "points" and "ranges".