A token, in XPath as elsewhere in the XML world, is a simple, discrete string of Unicode characters. Individual characters within a token are not themselves considered tokens. If an XPath expression is analogous to a chemical molecule, the tokens of which it’s composed are the atoms. (And the individual characters, I guess, are the sub-atomic particles.)

If quotation marks surround the token, it’s assumed to be a string. If no quotation marks adorn the token, an XPath-smart application assumes that the token represents a node name.^[2] I’ll have more to say about nodes and their names in a moment and much more to say about them throughout the rest of the book. For now, though, consider the first example listed above. The bare token taxcut is the name of a node. If I had put it in quotation marks, like "taxcut", the XPath expression wouldn’t necessarily refer to anything in a particular document; it would simply refer to a string composed of the letters t, a, x, c, u, and t: almost certainly not what you want at all.

As a special case, a node name can also be represented with an asterisk (*). This serves as a wildcard (all nodes, regardless of their name) character. The expression taxcut/* locates all elements that are children of a taxcut element.

Tokens in an XPath expression are set off from one another using single-character delimiters, or pairs of them. Aside from quotation marks, these delimiters include:

While the rules for valid combinations of tokens and delimiters aren’t spelled out explicitly anywhere, they follow the rules of common sense. (Whether the sense is in fact common depends a little on how comfortable you are with the concepts of location steps and location paths.)

For instance, the following is a syntactically illegitimate XPath expression; it also, if you think a little about it, doesn’t make practical sense:

book/

See the problem? First, for those of you who simply want to follow the rules without thinking about them, you can simply accept as a given that the / (unless used by itself) must be used as a delimiter between location steps; with no subsequent location step to the right, it’s not separating book from anything.

Second, there’s a more, well, let’s call it a more philosophical problem. What exactly would the above expression be meant to say? “Locate a child of the book element which....” Which what? It’s like a sentence fragment.

I’ll cover these kinds of common-sense rules where appropriate. (See Chapter 3, especially.)

Most (but not all) nodes have names. To understand node names, you need to understand three terms:

These three kinds of name conform to common sense in most cases, for most nodes, but can be surprising in others. When covering node types, below, I’ll tell you how to determine the name of a node of a given type.

Nodes in a document are positioned within the document before or after other nodes. Take a look at this sample document:

<?xml-stylesheet type="text/xsl" href="invoice.xsl"?>
<statement acct="112233">
   <history>
      <credits>
         <payment date="2001-09-09" curr="EU">13.99</payment>
         <adjustment date="2001-09-30" curr="USD">12.64</adjustment>
      </credits>
      <debits>
         <fin_chg date="2001-09-09" curr="USD">1.98</fin_chg>
      </debits>
   </history>
   <current>
      <!-- No current charges for this customer? -->
   </current>
</statement>

If you were an XML parser reading this document from start to finish, you’d be following normal document order. The xml-stylesheet PI comes before any of the elements in the document, the history element precedes the current element, the fin_chg element precedes the comment contained by the current element, and so on. Also note that XPath considers the attributes to a given element to come before that element’s children and other descendants.

As you’ll see in Chapter 3, under the discussion of axes, it’s also possible to access nodes in reverse document order.

XML’s strict enforcement of document structure, even under simple well-formedness constraints, ensures that nodes don’t just have a simple document order — even the “nodes” in a comma-separated values (or other plain text) file do that much — but also a set of more complex relationships to one another. Some nodes are parents of others (which are, in turn, children of their parents), and nodes may have siblings, ancestors, and so on.

Because these family relationships are codified in the concept of XPath axes, I’ll defer further discussion of them until Chapter 3.

Every XML document has one and only one root node. This is the logical something that contains the entire document — not only the root element and all its contents, but also any whitespace, comments, or PIs that precede and follow the root element’s start and end tags. This “something” is analogous to a physical file, but there may be no precise physical file to which the root node refers (especially in the case of XML documents generated or assembled on the fly and not saved in some persistent form).

In a location path, the root node is represented by a leading / (forward slash) character. Any location path that starts with / is an absolute location path, instructing the XPath-aware application, in effect, to start at the very top of the document before considering the location steps (if any) that follow. The root node does not have an expanded-name. Its local-name is an empty string.

Each element node in the document is composed of the element’s start and end tags and everything in between. (Thus, when you retrieve a document’s root element, you’re retrieving everything in the document except any comments and PIs that precede or follow it.) Consider a simple code fragment:

<year>
   <month monthnum="4">April</month>
   <month monthnum="8">August</month>
   <month monthnum="12">December</month>
   <month monthnum="2">February</month>
   <month monthnum="1">January</month>
   <month monthnum="3">March</month>
   <month monthnum="5">May</month>
   <month monthnum="6">June</month>
   <month monthnum="7">July</month>
   <month monthnum="11">November</month>
   <month monthnum="10">October</month>
   <month monthnum="9">September</month>
</year>

This location path (which says, “Locate all month children of the root year element whose monthnum attributes have the value 3”):

/year/month[@monthnum="3"]

selects the sixth month element in the fragment — that is, the element whose contents (the string “March”) are bounded by the <month monthnum="3"> start tag and the corresponding </month> end tag. To emphasize, and to repeat a point made early in this chapter: while the physical representation of the element is bounded by its start and end tags, XPath doesn’t have any understanding at all of tags or any other markup. It just gets a particular invisible box corresponding to this physical representation and holding its contents. Importantly, though, it selects the element as a single node with various properties and subordinate objects (a name, a string-value, an attribute with its value).

You sometimes must take care, when selecting element nodes, not to be confused by the presence of “invisible whitespace” in their string-values.

Yes, true: all whitespace is invisible. (That’s why it’s called whitespace, right?) But the physical appearance of XML documents can trick you into thinking that some whitespace “doesn’t count,” even though that’s not necessarily true. For instance, consider Figure 2-2, depicting a greatly simplified version of a document in the same vocabulary we’ve been using in this section.

Figure 2-2. An XML document with no whitespace

In this figure, as you can see, there’s no whitespace in any of the document’s content, only within element start tags (and not always there). While many real-world XML documents (especially those that are machine generated) appear this way, it’s just as likely that the documents you’ll be excavating with XPath will look like Figure 2-3.

Figure 2-3. The same XML document with whitespace

The human eye tends to ignore the whitespace-only blocks of text (represented with gray blocks in the figure) in a document like this one, discarding them as insignificant to the document’s meaning. But XML parsers, bound by the XML spec’s “all text counts” constraint, are not free to ignore these scraps of whitespace. (Some parsers may flag the whitespace as potentially “insignificant,” leaving to some higher-order application the task of ignoring it or not.) So consider now the effect of an XPath expression such as the following, when applied to the document in Figure 2-3:

/year

This location path doesn’t return just the year element node, the month element node and its attribute. It also returns:

Whether this will present you with a problem depends on your specific need. If it is a problem, there’s an XPath function, normalize-space( ) (covered in Chapter 4), that trims all leading and trailing whitespace from a given element’s content.

The local-name of an element node is the name of the element type (that is, its generic identifier (GI), as it appears in the element’s start and optional end tags). Thus, its expanded-name equals either its local-name (if there isn’t a namespace in effect for that element) or its associated namespace URI paired with the local-name. Consider this code fragment:

<xsl:stylesheet version="1.0"
   xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
   <xsl:template match="/">
      <html>
         ...
      </html>
   </xsl:template>
</xsl:stylesheet>

All elements in this document whose names carry the xsl: prefix are in the namespace associated with the URI “http://www.w3.org/1999/XSL/Transform.” Thus, the expanded-name of the xsl:stylesheet element consists of that URI paired with the local-name, “stylesheet.”

http://www.w3.org/1999/XSL/Transform+stylesheet

{http://www.w3.org/1999/XSL/Transform}stylesheet

Attributes, in a certain sense, “belong to” the elements in which they appear, and in the same sense, they might be thought to adopt the namespace-related properties of those elements. For instance:

<xsl:template match="/" />

Logically, you might conclude that the match attribute is “in” the same namespace as the xsl:template element — it does, after all, belong to the same XML vocabulary — and that it, therefore, has something like an implied namespace prefix.

This isn’t the case, though. An attribute’s QName, local-name, namespace URI, and hence, expanded-name are all determined solely on the basis of the way the attribute is represented in the XML source document. Attributes such as match in the above example — with no explicit prefix — have a null namespace URI. That is, unprefixed attributes are in no namespace, including the default one; thus, their QName and local-name are identical.

Note that namespace declarations, which look like attributes (and indeed are attributes, according to the XML 1.0 and “Namespaces in XML” Recommendations), are not considered the same as other attributes when you’re using XPath. As one example, the start tag of a typical xsl:stylesheet root element in a typical XSLT stylesheet might look something like this:

<xsl:stylesheet version="1.0"
   xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
   xmlns="http://www.w3.org/1999/xhtml">

A location path intended to locate all this element’s attributes might be:

/xsl:stylesheet/@*

(As a reminder, the wildcard asterisk here retrieves all attribute nodes, regardless of their names.) In fact, this location path locates only the version attribute. The xmlns:xsl and xmlns attributes, being namespace declarations instead of “normal” attributes, are not locatable as attribute nodes.

Processing instructions, by definition, stand outside the vocabulary of an XML document in which they appear. Nonetheless, they do have names in an XPath sense: the name of a PI is its target (the identifier following the opening <? delimiter). For this PI:

<?xml-stylesheet type="text/css" href="mystyle.css"?>

the QName and local-name are both xml-stylesheet. However, because a PI isn’t subject to namespace declarations anywhere in a document — PIs, like unprefixed attributes, are always in no namespace — its namespace URI is null.

The other thing to bear in mind when dealing with PI nodes is that their pseudo-attributes look like, but are not, real attributes (hence, the “pseudo-” prefix). From an XPath processor’s point of view, everything between the PI target and the closing ?> delimiter is a single string of characters. In the case of the PI above, there’s no node type capable of locating the type pseudoattribute separate from the href pseudoattribute, for example. (You can, however, use some of the string-manipulation functions covered in Chapter 4 to tease out the discrete pseudoattributes.)

Each comment in an XML source document may be located independently of the surrounding content. A comment has no expanded-name at all, and thus has neither a QName, a local-name, nor a namespace URI.

Any contiguous block of text — an element’s #PCDATA content — constitutes a text node. By “contiguous” here I mean that the text is unbroken by any element, PI, or comment nodes. Consider a fragment of XHTML:

<p>A line of text.<br/>Another line.</p>

The p element here contains not just one but two text nodes, “A line of text.” and “Another line.” The intervening br element breaks them up into two. The presence or absence of whitespace in the #PCDATA content is immaterial. So in the following case:

<p>A line of text.
Another line.</p>

there’s still a single text node, which, like a comment, has no expanded-name at all.

Namespace nodes are the chimeras and Loch Ness monsters of XPath. They have characteristics of several other node types but at the same time are not “real,” but rather fanciful creatures whose comings and goings are marked with footprints here and there rather than actual sightings.

The XPath spec says every element in a given document has a namespace node corresponding to each namespace declaration in scope for that element:

Here’s a simple fragment of an XSLT stylesheet:

<xsl:stylesheet version="1.0"
   xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
   xmlns="http://www.w3.org/1999/xhtml">
  
   <xsl:template match="/">
      <html xmlns:xlink="http://www.w3.org/1999/xlink/namespace">
      ...
      </html>
   </xsl:template>
  
</xsl:stylesheet>

Three explicit namespace declarations are made in this fragment:

The namespace declarations for the xsl: and default namespace prefixes both appear in the root xsl:stylesheet element’s start tag; therefore, they create implicit namespace nodes on every element in the document — including those for which those declarations might not seem to make much sense. The html element, for instance, will probably not be able to make much use of the namespace node associated with the xsl: prefix. Nonetheless, in formal XPath terms that namespace node is indeed in force for the html element.

The namespace declaration for the xlink: prefix, on the other hand, is made by a lower-level element (html, here). Thus, there is no namespace node corresponding to that prefix for the higher-level xsl:template and xsl:stylesheet elements.

Each namespace node also has a local-name: the associated namespace prefix. So the local-name of the namespace node representing the XSLT namespace in the above document is “xsl.” When associated with the default namespace, the namespace node’s local-name is empty. The namespace URI of a namespace node, somewhat bizarrely, is always null.

The XML Information Set (commonly referred to simply as “the Infoset”) is a W3C Recommendation published in October 2001 (http://www.w3.org/TR/xml-infoset/). Its purpose, as stated in the spec’s Abstract, is to provide “a set of definitions for use in other specifications that need to refer to the information in an XML document.”

The definitions the Infoset provides are principally in terms of 11 information items: document, element, attribute, processing-instruction, unexpanded entity reference, character, comment, document type declaration, unparsed entity, notation, and namespace. As you can see, there’s a certain amount of overlap between this list and the node types available under XPath — and also a certain number of loose ends not provided at all by one or the other of the two Recommendations.

XPath 2.0 will resolve the conflicts in definitions of Infoset information items and XPath node types; at the same time, XPath will continue to need things the Infoset does not cover. For instance, XPath does not generally need to refer to atomic-level individual character information items. Instead, it needs to refer to the more “molecular” text nodes. For these “needed by XPath but not defined under the Infoset” information items, XPath 2.0 will continue to provide its own definitions.

For more information about XPath 2.0 and the Infoset, refer to Chapter 5.