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

The XPath Evaluation Context

XPath was designed as an expression language that could be embedded in other languages. The first such language was XSLT, but it was always envisaged that this would only be one of many host languages. Subsequent experience has shown that this did indeed happen: XPath (sometimes in the form of a restricted subset) has been used not only within XSLT and XPointer but also within a variety of programming languages such as Java and Perl, and also as a sublanguage for expressing constraints within XForms and XML Schema.

To make XPath suitable for this role as a sublanguage, there needs to be a clear interface between XPath and the host language. This interface specifies what information is provided by the host environment to the XPath environment, and the sum total of this information is referred to as the
evaluation context
.

The evaluation context can be split into two halves: information that is available at compile time (while the XPath expression is being parsed and checked for static errors) and information that is available only at runtime. These two parts are called the static context and the dynamic context, and they are described in the next two sections of this chapter.

An XPath host language such as XSLT should always specify how the static and dynamic context for XPath expressions are set up. Some aspects of the context may be under user control, some may have fixed values, and other parts may be completely implementation defined. This will vary from one host language to another. As far as XPath is concerned, it doesn't matter whether the information is fixed in the host language specification or whether it is provided by the vendor or by the user: the information is there somehow, and it is available for use.

As I describe each part of the evaluation context in the following sections, I will explain both how things work when you use XPath from XSLT, and the more general rules that apply in other environments.

The Static Context

The static context contains information that's needed while performing the analysis or compilation phase on an XPath expression.

In many environments, XPath is a “load and go” technology: you submit an expression as a string, and it is compiled and executed straight away. In this case, the distinction between the static context and the dynamic context isn't all that important. In other environments, however, there is a distinction. XSLT stylesheets are often compiled once and then executed many times, and the XPath expressions within the stylesheet will typically be compiled when the stylesheet is compiled (usually not into machine code, but into some intermediate form that a runtime interpreter can later process). So it's worth making the distinction between the two phases even if they are often combined.

The various parts of the static context are described in the sections that follow.

XPath 1.0 Compatibility Mode

We've generally referred to this as
backward-compatibility mode
, which is what XSLT calls it. This value is a boolean: compatibility mode is either on or off. Compatibility mode will be switched on when users want the effect of an XPath expression to be as close as possible to the effect that the same expression would have had under XPath 1.0.

In XSLT, compatibility mode for XPath expressions in a stylesheet is switched on by setting the
version
attribute to
1.0
, either on the

element or on an inner element in the stylesheet if it is required only for certain expressions and not for others. If the stylesheet specifies
version=“2.0”
, then 1.0 compatibility mode will be off.

XPath processors (and XSLT processors) are not obliged to offer XPath 1.0 compatibility mode. It's seen as a transition aid rather than as a permanent feature of the language.

Setting XPath 1.0 compatibility mode does not mean that everything in the language is 100% backward compatible, though it gets close. Appendix C contains a list of the incompatibilities that remain; most of them are corner cases that few users are likely to encounter, but one or two are more significant.

So what exactly changes if you set 1.0 compatibility mode? The following rules are applied only when in this mode:

• We have already seen, earlier in this chapter (page 549), how the function calling rules are affected. In summary, a supplied sequence may be truncated to its first value, and arguments of any type may be converted to strings or numbers if that is what the function expects.
  
• Similar rules apply to arithmetic operators such as
  +
  and
  div
  . These are described in Chapter 8. They are treated in the same way as a function that expects two
  xs:double
  arguments—the supplied operands are converted to
  xs:double
  using the
  number()
  function, and the arithmetic is performed in double-precision floating point.
  
• In an expression using one of the operators
  =
  ,
  !=
  , if one of the operands is numeric, then the other operand is converted to an
  xs:double
  value by applying the
  number()
  function. If the operator is one of
  <
  ,
  <=
  ,
  >
  ,
  >=
  , then both operands are converted to
  xs:double
  values. There are also special rules when one of the arguments is an
  xs:boolean
  value.