2.2 XPath: XML Path Language

XPath is a language for addressing parts of an XML document and was originally designed to be used by both XSLT and XPointer. XPath gets its name from its use of a path notation, as in URLs, for navigating through the hierarchical structure of an XML document. XForms uses XPath 1.0 ^[1] to bind user interface controls to the XForms model. This was illustrated in the questionnaire example in Figure 1.5 where we used XPath expression /person/age as the value of attribute ref on user interface control input to bind it to the data model.

^[1] http://www.w3.org/tr/xpath

The primary purpose of XPath is to address parts of an XML document. In support of this primary purpose, it also provides basic facilities for manipulation of strings, numbers , and booleans. ^[2] XPath uses a compact syntax to facilitate use of XPath within URIs and XML attribute values. This aspect of XPath makes it suitable to be a minimalistic expression language within XML documents.

^[2] XPath 2.0 has a richer set of data types and is a work in progress at the time of writing. Future versions of XForms are likely to use XPath 2.0.

XForms also uses XPath to express interdependency constraints among fields in an application. Such constraints are recalculated as the user interacts with the form; this can be used to advantage in creating dynamic Web interfaces. Unlike languages like ECMAScript, XPath is not a Turing-complete programming language; this ensures that the ability to encode interdependencies among fields is not abused by complex scripts to consume excessive resources on the client. In addition, it preserves the declarative nature of XForms applications. As a language designed for working on XML tree structures, nodes and node-sets are the most important object types when working with XPath expressions.

XPath expressions are evaluated with a given context node and in a given evaluation environment . Informally, the context node determines the portion of the tree relative to which the expression is evaluated. The environment determines the variable bindings that are in scope and the functions that are available, as well as the namespace declarations that are in effect.

XPath leaves it to the host language, for example, XSLT, to specify the rules used to determine the context ; additionally, the host language is free to supply an appropriate library of functions. The rules used by XForms in determining the evaluation context are defined formally by the XForms 1.0 specification and will be explained in detail in later chapters of this book.

2.2.1 Location Paths

XPath expressions that address a node (or set of nodes) are called location paths . A location path selects a set of nodes relative to the context node. Location paths are evaluated from left to right, that is, given the expression /person/age , the first portion, /person , is evaluated to locate the node-set consisting of all person nodes occurring at the root. Next, the expression age is applied to this set to locate all age children of all /person nodes.

Formally, ^[3] location paths are either relative or absolute . A relative location path consists of a sequence of one or more location steps separated by / . The steps in a relative location path are composed together from left to right. Each step in turn selects a set of nodes relative to a context node. An initial sequence of steps is composed together with a following step as follows :

^[3] This description is taken from the XPath 1.0 specification.

The initial sequence of steps selects a set of nodes relative to a context node.
Each node in that set is used as a context node for the following step.
The set union of the sets of nodes identified by that step is the final result.

An absolute location path consists of an initial / , optionally followed by a relative location path. A / by itself selects the root node of the document containing the context node. If it is followed by a relative location path, then the location path selects the set of nodes that would be selected by the relative location path relative to the root node of the document containing the context node.

For the questionnaire example shown in Figure 1.12, the subtlety of this left-to-right evaluation rule does not matter because there is only one person child of the root element. However, it is important to remember that XPath location paths always work in terms of node-sets; this is important when understanding filters in location paths.

A filter is an XPath expression that is used to test the nodes in a node-set. Filters are typically used to select a subset of the nodes returned by a location path. Note that although sets in the traditional sense are unordered , members of XPath node-sets are treated in document order. For example, an XPath filter expression that selects nodes having a specific attribute might be used to filter a node-set. Other commonly used filters select the first or last element of a given node-set. As an example, if the person structure in our questionnaire example holds multiple address elements as direct children of person , we might use the expression

 /person/address[1]

to select the first of these address elements.

Assuming that each address element contains an attribute type indicating the address type, we might use the expression

 /person/address[@type='work']

to locate the work address.

2.2.2 Location Path Syntax

Location paths in XPath consist of three logical components :

An axis, for example, all children of this node
A node test, for example, the name of the node to select
Optional sets of predicates, each enclosed in [] that specify expressions to filter the selected set of nodes

Table 2.1. XPath Abbreviated Syntax for Use in Location Paths

Syntax	Description	Example
`.`	self	`./age`
`..`	parent	`../address`
`@`	attribute	`address/@type`
`*`	all children	`address/*`
`@*`	all attributes	`address/@*`
`//`	all descendants	`person//address`

The XPath specification first describes the semantics of location paths in terms of an unabbreviated syntax and then describes the mapping to the abbreviated syntax used in this book. The XPath specification formally defines the various axes that can be used in constructing location paths; the abbreviated syntax covers all the axes that are commonly encountered when authoring XForms.

We summarize this abbreviated syntax in Table 2.1. Special note should be made of the syntax // used to select descendants of a given node; this selects all matching descendants starting from the context nodes. Thus, given an HTML document, the expression body//p would select all p elements that occur anywhere in the body of the document.

2.2.3 Variables, Functions, and Expression Evaluation

Variable ^[4] references use the syntax $v ; function calls take the form f(a1,...) . The definition of the function or the value of a variable is looked up in the current evaluation environment. The XPath specification defines a core set of functions that operate on the basic XPath typesnode-set, string, boolean, and number. In addition, XForms 1.0 defines a set of functions for use in XForms.

^[4] Note that XForms 1.0 does not use XPath variable references.

XPath contains a core set of operators used in constructing expressions; these operations use the same syntax as found in most programming languages and will not be described here. A key difference to note is that since XPath uses / as the path separator character, the division operator is written 3 div 2 . XPath also provides a mod operator that is the same as the % operator in ECMAScript. We conclude this section with examples of XPath expressions that one might encounter when creating common Web applications using XForms, as in Table 2.2.

Table 2.2. Expressions Commonly Found in XForms Web Applications

Expression	Description
`count(person/children)`	Number of children
`price * tax-table[@state='NY']`	Compute tax
`camera[@price=min(../camera/@price)]`	Cheapest cameras
`sum(cart/item/@price)`	Price of items in cart
`avg(person/income)`	Average income