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

1.
In backward-compatibility mode, if one of the operands is a singleton boolean value, then the other operand is replaced by its effective boolean value. The comparison then proceeds by applying the rest of the rules, although both operands are now singletons. This rather strange rule made more sense in XPath 1.0, and it is therefore retained in compatibility mode, but it very rarely affects the outcome. For the rules on effective boolean value, see the description of the
boolean()
function on page 721.

2.
Each of the operands is atomized. This means that if the operand starts out as a sequence of nodes, the process turns it into a sequence of atomic values. There may be more atomic values than nodes (if some of the nodes are defined in the schema to contain a list), or fewer (if some of them contain empty lists). The original operand may contain atomic values as well as nodes, and the atomization process leaves these atomic values alone.

3.
The remaining rules are applied to compare each pair of items from the two sequences, taking one value in the pair from the first sequence and the other value from the second sequence. This means that if one sequence contains four items, and the other contains five, then each item in the first sequence must be compared with each item in the second, giving 20 comparisons to be done in total. If any of these comparisons is true, the result of the general comparison is true. If they are all false, the result is false. If any of the comparisons fails with an error, the general comparison as a whole fails. However, it's not defined in what order the comparisons are done, so if there's a pair of items for which the comparison is true, and another pair for which it raises an error, then the final result might be either true or an error.

4.
Considering each pair of items from the two sequences in turn, if one item of the pair is an
xs:untypedAtomic
value (typically, a value extracted from a node in a schema-less document), then it is converted to a more specific type. If both items in the pair are
xs:untypedAtomic
values, then they are both converted to
xs:string
values. If only one item is an
xs:untypedAtomic
value, then it is converted to the type of the other item. There is a special rule when the second item is numeric: in this situation the
xs:untypedAtomic
value is always converted to an
xs:double
value. This caters for a situation such as comparing the untyped value
2.1
with the
xs:integer
value
2
; it would be unreasonable to convert the value
2.1
to an integer before doing the comparison.

5.
There is now a further rule that comes into play only when backward-compatibility mode is enabled. This is that if one of the items in the pair is numeric, and the other is not, then the non-numeric item is converted to an
xs:double
using the
number()
function. If the value isn't numeric, this returns
NaN
, and the comparison will be false. But a comparison such as
“23”=23
is allowed, and will succeed, under the backward compatibility rules. In pure XPath 2.0 mode, comparison of a string to a number is not allowed; you have to convert one of the operands explicitly to the type of the other, to make it clear whether a string comparison or a numeric comparison is intended.

6.
Finally, after any conversions defined in steps 4 and 5, the two items are compared using the rules for the corresponding value comparison operator: that is, one of
eq
,
ne
,
lt
,
le
,
gt
, and
ge
, depending on whether the original operator was
=
,
!=