XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition (356 page)
Read XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition Online
Authors: Michael Kay
Despite all the efforts to make the
eq
operator transitive, it turns out that in corner cases, it isn't. This problem arises because of the numeric promotion rules. Given three numbers
xs:float(‘1.0’)
,
xs:decimal(‘1.0000000000100000000001’)
,
xs:double(‘1.00000000001’)
, the float and the double are both equal to the decimal, but they are not equal to each other. This turns out to create quite a problem for operations that rely on transitivity, notably the
distinct-values()
function and the
Examples of Value Comparisons
| Expression | Description |
| $x eq 2 | This is true if $x is a sequence of exactly one item, and that item is an instance of xs:double , xs:float , or xs:decimal (or a type derived from these by restriction) that is numerically equal to 2. It is also true if the single item in $x is a node whose typed value is one of these numeric types and is numerically equal to 2. The result is false if the item in $x is a different numeric value, and it is effectively false if $x is empty. If $x contains more than one item, or contains a non-numeric value, or if it is an untyped node, the result is an error. |
| count($x) gt 2 | This is true if the number of items in the sequence $x is 3 or more, and it is false otherwise. No type error can occur in this case, because the value returned by the count() function will always be an integer, and count() accepts any type of value as its argument. |
| @x eq “yes” | This is true if the context node has an attribute named x, and the type of that attribute is either xs:string or xs:untypedAtomic or a type derived from xs:string by restriction, and the value of the attribute compares equal to the string  yes under the rules of the default collation (which is context-dependent). If the attribute doesn't exist, then the effective value is false. If the attribute has a different type, the result is a type error. |
| @retirement-date ge current-date() | This is true if the context node has an attribute named retirement-date , and the type of that attribute is xs:date or a user-defined type defined as a restriction of xs:date , and the value of the attribute is the same as or after the current date. In the unlikely event that the retirement-date attribute has a timezone associated with it, this will be taken into account in the comparison; if not, the implicit timezone is used, which will always be the same as the timezone used in the result of the current-date() function. If the retirement-date attribute does not exist the effective result is false. If the attribute has any type other than xs:date , including the case where it has type xs:untypedAtomic , a type error occurs. |
General Comparisons
The term
general comparisons
is used for expressions involving the six operators=,!=,<,<=,>, and>=. These operators are retained and generalized from XPath 1.0. As we shall see, they are considerably more powerful than their counterparts used in value comparisons, but this also means that they may be rather more expensive, and they can also lead to a few surprises—they don't always give the answer you expect.