XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition (324 page)

The specification makes provision for some documents and/or collections to be recognized by the system at compile time. For example, you might compile an XPath expression against a particular database, and you might know that all the documents in that database, or in some part of that database, have been validated against a particular schema. This knowledge might allow the system to know that the example expression above is type-safe. Without this knowledge, to get this query past a system that does static type checking you would need to change it to:

This is obviously very inconvenient. It's no surprise that most of the vendors who are planning to implement static type checking in their products are running in a database environment, where the schemas are all known in advance.

This discussion probably affects XQuery much more than it does XPath. Most vendors of XML databases are using XQuery rather than XPath as the query language (though some offered XPath as a stop-gap). There's nothing intrinsic to the argument, however, that makes it only relevant to XQuery, and that's why this information is also part of the static context in XPath.

The Dynamic Context

We've now finished our tour of the static context, which contains all the information available at compile time about the environment in which an XPath expression will run. We'll now look at the information that's available at execution time.

In principle, all the information that was available in the static context remains available to the XPath processor when evaluating the query. The dynamic context supplements this with additional information. In practice, however, the XPath processor is free to discard information that it will not need at runtime. For example, it doesn't need to know the names of variables at runtime, it only needs to know where the values of the variables will be held.

The following sections look at the different parts of the dynamic context in turn.

The Focus

The
focus
is a collective term used to describe three important pieces of information in the dynamic context: the context item, the context position, and the context size.

The most important of these is the context item. Consider the simple path expression
@code
. This selects an attribute named
code
. But an attribute of what? This expression only makes sense if the context item identifies an element node. The expression then selects the
code
attribute of that element. When an XPath expression like this is embedded in some host language, it is the job of the host language to define how the context item is initialized.

The term
context node
is often used to mean “the context item, assuming it is a node”. Very often the context item will be a node, but it can also be an atomic value such as a string or a number.

In an XSLT template rule, for example, the context node is the node that was matched by the template rule. So if you write:

then the XPath expression
@code
is evaluated with the matched

element as the context node.

To see the effect of the context position and size, it's probably easiest to look at an

instruction; for example:

The XPath expression
.
, used in the

instruction, simply selects the context item. The instruction then writes a text node containing the value of this item converted to a string.

The function
position()
returns the value of the context position, and the function
last()
returns the value of the context size. In an

instruction, each item in the selected sequence (here, each

element) is processed in turn. While each item is being processed, it becomes the context item, and its position in the sequence of items being processed becomes the context position. Positions are always numbered starting at one. The context size is the number of items in the sequence, which of course is the same for each of the items. So the test
!=
last()”>,

outputs a comma after every item except the last.