The W3C’s new XML Pointer (XPointer) standard provides a method for identifying pieces or fragments of an XML document. XPointer extends the XPath standard and reuses many of the same concepts, evaluation rules, and syntax. But there’s more to it than just that.
Let's take a look at the various aspects of the new XPointer standard and the W3C recommendations you can peruse to obtain more information. As I discuss the standards, I'll also provide some examples that will refer to the XML document found in Listing A.
An XPath backgrounder
Since XPointer and XPath are related standards, it’s important to understand the latter before discussing the former. For an overview of the capabilities of XPath, I’d recommend taking a look at the Builder.com article “Locate and format XML data with XPath functions.”
In its simplest form, an XPointer statement looks a lot like a standard URI that’s had a pound-sign (#) pre-pended and a fragment identifier stuck on the end. The fragment identifier is itself formally known as the XPointer, and it will invoke a real feeling of déjà vu in anyone who has ever hand-coded XHTML. However, comparing XPointers to XHTML anchors is a great simplification; XPointers are more than hard-coded links within a document.
Overview of the XPointer recommendation
The WC3 maintains four recommendation documents, each covering a different aspect of the XPointer language, its features, and its capabilities. I’d recommend that anyone interested in XPointer become familiar with the contents of these documents. You should understand though, that because these documents are only proposed recommendations, the final versions may in fact be quite different from the current versions, in much the same way that alpha and beta versions of software are different from the final shrink-wrapped product.
The XPointer Framework
The XPointer Framework document describes the Internet media types that the XPointer proposed recommendations apply to, as well as describing the syntax of the XPointer language. XPointer is currently intended for use with the any of the following Internet media types:
- · Text/xml
- · Application/xml
- · Text/xml-external-parsed-entity
- · Application/xml-external-parsed-entity
- · XPointer element() Scheme Document
The XPointer xpointer() Scheme
The redundantly named XPointer xpointer() Scheme document describes the syntax for the XPointer language in detail. This document includes the definitions for the terms point, range, location, and location sets. Briefly, a point is a single location in an XML document that has no content; a range point is the content between two points; a location is roughly the equivalent to a node in XPath; and a location-set is the equivalent of an XPath node-set.
In addition to these somewhat circular definitions of terms and concepts, the document includes descriptions, syntax, and examples of the various XPointer functions, which are briefly described in Table A.
The XPointer element() Scheme
The purpose of the XPointer element() Scheme document is to describe how, in conjunction with the XPointer Framework, you’d use XPointer to address XML elements in an application. For example, the following code identifies the first child element of the root node, which in the case of Listing A would be the first item node.
The XPointer element() Scheme is a bit like a Swiss Army knife—there is usually more than one tool for any particular job. For example, you could achieve the same results by coding any of the following possibilities:
The XPointer xmlns() Scheme
Finally, we have the XPointer xmlns() Scheme document, which describes the XML namespace used for XML Pointers, including namespace prefixes and namespace qualified names.
XPointer versus XPath
As I indicated, XPointer is described in the framework document to be an extension of XPath, but in reality, this is an oversimplification. Like XPath, XPointer can identify both nodes and node sets within a document, but XPointer has the additional capability of addressing both ranges of nodes and points within an XML document. To demonstrate this, consider the following statements:
If run on the document in Listing A, the above code creates a location set consisting of two string locations, denoting the two occurrences of the string "electronics" in the document.
This command results in a point, or a location in an information set with no content or children, that represents the location immediately following the <root> in the XML document shown in Listing A.
Neither of these tasks would have been possible using XPath, which is a major reason why the XPointer standard is being developed.
Personally, I’m one of those people who like to learn by doing. The problem with this, though, is that often I jump on a new technology when it's too new for me to really do anything with it. But learning about something theoretically, before there are any implementations, is frankly no fun.
Even though the XPointer specification is (as of this writing) only a recommendation, because of its flexibility and power it warrants a closer look. Either by itself or in combination with XPath, it provides the capability to access and manipulate XML documents in ways that were unimaginable before.