XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition (354 page)
Read XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition Online
Authors: Michael Kay
In nearly all cases the four operators have the obvious relationship to each other; for example, if
$a lt $b
is true, then$a le $bis also true, as is$b gt $a. The one exception is the
xs:double
(and
xs:float
) value
NaN
. If
NaN
appears as either operand of any of these four operators, or as both operands, then the result is always false.
Type Checking for Value Comparisons
The operands in a value comparison are processed according to the following rules. These rules apply to all six operators. Note that there are no special backward-compatibility rules here, because these operators were not available in XPath 1.0.
1.
Each of the operands is atomized, as described on page 220 in Chapter 5. This means that when you supply a node as the argument, the typed value of the node is extracted.
2.
If either operand (after atomizing) is a sequence containing more than one value, then a type error occurs.
3.
If either operand (after atomizing) is an empty sequence, the result is an empty sequence.
4.
If either of the operands (after atomizing) is of type
xs:untypedAtomic
(which will generally be the case if the value has been extracted from an element or attribute in a schema-less document), then it is converted to a string (a value of type
xs:string
). This is true even if the other operand is a number.
5.
If the two values are not comparable then a type error occurs. This can happen because their types are incompatible with each other (for example one is an
xs:string
and the other an
xs:decimal
), or it can happen because both values belong to a type for which ordering is not defined, such as
xs:QName
.
6.
Otherwise, the values are compared according to the ordering rules for their data type, as described in the table in the previous section.
There are a couple of controversial decisions reflected in these rules.
The first is that either operand is allowed to be an empty sequence. The specification vacillated on this question in early drafts.
The main argument in favor of allowing an empty sequence is that the empty sequence should behave like a null value in SQL—any operator or function that has()as an argument should return()as a result. This also makes it easier to handle optional elements and attributes. This principle has not been followed systematically throughout the language, but it is followed by most of the operators. At one stage the language design also included SQL-like three-valued logic, but this was dropped, largely because it was incompatible with XPath 1.0. In most cases, XPath 1.0 and now also XPath 2.0 treat absent data in almost exactly the same way as SQL, but without relying on three-valued logic. For example, in an expression such as//item[@code eq 3], items that have no
code
attribute will not be selected. Equally, if you write//item[@code ne 3], items that have no
code
attribute will not be selected. (In both cases, the value of the predicate is an empty sequence, and the effective boolean value of an empty sequence is false). But unlike SQL, the XPath expression//item[not(@code=3)]does select items with no
code
attribute. The SQL rule thatnot(null)returnsnull