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

• The
  select
  attribute of
  
  
• The value of an attribute value template
  
• The
  value
  attribute of
  
  
• The value of a sort key
  

In all these cases XSLT 1.0 discards any selected node after the first. In the first three cases, XSLT 2.0 outputs all the values, with an appropriate separator. In the final case XSLT 2.0 reports an error.

In XPath 2.0, if a sequence containing more than one value is supplied in a context where a single value is expected (notably as an operand of an arithmetic expression or as an argument to a function where a singleton is expected), then an error (XPTY0004) is reported.

If your stylesheets fall foul of this change when you switch backward compatibility off, it's easy to fix. If the current code is, for example,

, change it to

. Remember to use parentheses where necessary.

Type Checking of Function Arguments

With a few exceptions such as the
string()
,
number()
, and
concat()
functions, XPath 2.0 will not implicitly convert a supplied value to the required type. This means, for example, that you can no longer do
starts-with($x, ‘-’)
to test whether the number
$x
is negative: you must first convert it to a string. The conversion still occurs, however, if the value is
untypedAtomic
.

This also applies to operators such as the arithmetic operators. The remedy is to do an explicit conversion to the required type using a constructor function or cast, as described in Chapter 11.

Comparison Operators

In XPath 1.0, the operands of
<
and
>
were automatically converted to numbers, and a numeric comparison was performed. If either value could not be converted to a number, the result would be
false
. In XPath 2.0, this conversion no longer happens, unless one of the values is
untypedAtomic
and the other is a number. So the comparison
@price > 20
still does a numeric comparison, but assuming the document is untyped,
@price > @discount
now does a string comparison.

In XPath 1.0, if either of the operands of
<
,
>
,
=
, or any of the other comparison operators was a boolean value, the other operand would be converted to a boolean value. This is no longer the case: instead, the comparison has the same existential semantics as usual. For example,
@married = true()
in XPath 1.0 would test if the attribute
married
exists; in 2.0 it tests whether the result of atomizing the attribute is equal to the value
true()
.