XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition (298 page)
Read XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition Online
Authors: Michael Kay
The second group of operators can be classified as type operators. These take two operands, one of which is a value, the other a type. The operators in this category are:
- instance of
- cast as
- castable as
- treat as
Again, none of these words are reserved in any way. All these operators, together with the syntax for describing a type, are fully described in Chapter 11.
The final group of operators are best described as higher-order operators. These are characterized by the fact that they don't simply evaluate their operands and combine the resulting values: each has its own rules for how the different subexpressions contribute to the final result. These operators have custom syntax that doesn't always look like a conventional operator at all. They are shown in the following table.
| Expression | Meaning |
| for $x in E1 return E2 | Evaluates E2 once for every value in E1, concatenating the resulting sequences. |
| some $x in E1 satisfies E2 | Returns true if E2 is true for any item in E1. |
| every $x in E1 satisfies E2 | Returns true if E2 is true for every item in E1. |
| if (E1) then E2 else E3 | Evaluates E2 or E3 depending on the value of E1. |
| E1 / E2 | Evaluates E2 once for every value in E1, returning a sequence of nodes in document order. |
| E1 [ E2 ] | Returns those items in the sequence E1 for which E2 evaluates to true. |
This concludes our survey of the lexical constructs in an XPath expression. We will now look at the basic syntactic building blocks, which are referred to as primary expressions.
Primary Expressions
Primary expressions are the most basic kinds of expression in XPath, and ultimately, all XPath expressions are constructed by combining primary expressions using various operators. The following sections in this chapter describe each kind of primary expression. These are described by the syntax:
| Expression | Syntax |
| PrimaryExpr | Literal | VariableReference | ParenthesizedExpr | ContextItemExpr | FunctionCall |
| Literal | NumericLiteral | StringLiteral |
| NumericLiteral | IntegerLiteral | DecimalLiteral | DoubleLiteral |
We have already covered numeric and string literals earlier in the chapter. The rest of the chapter therefore concentrates on the four other kinds of primary expressions: variable references, parenthesized expressions, the context item expression, and function calls.
The only real thing that these different kinds of
PrimaryExpr
have in common is the context in which they can be used.
According to the syntax rules, any
PrimaryExpr
can be followed by a predicate to form a
FilterExpr
, so for example
17[1]
and‘Berlin’[3]are both legal. And in fact, in XPath 2.0 these expressions are not only syntactically legal, they also make sense semantically: a single item such as17or‘Berlin’is a sequence of length one, and applying a predicate to it can return either that item or an empty sequence. Filter expressions are described in Chapter 8.
Examples
| Expression | Description |
| 23.5 | A NumericLiteral is a PrimaryExpr |
| ‘Columbus’ | A StringLiteral is a PrimaryExpr |
| $var | A VariableReference is a PrimaryExpr |
| contains(@name, ‘#’) | A FunctionCall is a PrimaryExpr |
| (position() + 1) | A parenthesized expression is a PrimaryExpr |
The notable omission from the list of primary expressions is
AxisStep
: an axis step such aschild::node()is not a
PrimaryExpr
, even though it contains no other expressions. This ensures that an expression such aspara[1]is unambiguously a
PathExpr
, with the predicate[1]taken as part of the
Step
, rather than it being a
FilterExpr
consisting of a
PrimaryExprparafollowed by a
Predicate[1]. It is possible to turn an
AxisStep
into a
PrimaryExpr
by putting it in parentheses, so(para)[1]is a
FilterExpr
. In this case the meaning is the same, but this will not always be the case.