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

To be sure of avoiding this failure, you need to rewrite the expression as:

The reason this change was made is that changing the order of evaluation of expressions within a predicate is a common technique used by database optimizers to take maximum advantage of indexes present in a database. The existing rule in XPath 1.0 prevented many such optimizations. This of course is more likely to affect XQuery than XPath implementations, but the rule was changed in both languages to keep them consistent. A vendor who wishes to offer the maximum level of backward compatibility can of course continue to implement boolean expressions in the same way as XPath 1.0.

I think it's unlikely that many existing stylesheets or freestanding XPath expressions will be affected by this change, if only because runtime errors in XPath 1.0 are extremely rare: most programming mistakes in XPath 1.0 produce either a syntax error, or wrong answers, but not a runtime failure.

Other XSLT Differences

XSLT 2.0 reports a compile-time error if an

instruction supplies a value for a parameter that is not declared in the called template. XSLT 1.0 simply ignored the extra parameter.

With the
key()
function, XSLT 1.0 converted both the stored value and the supplied value to strings before comparison. XSLT 2.0 compares them without conversion. If they are of different types, they are regarded as not matching (and
untypedAtomic
is treated as
string
). So a call on
key(‘k’, 12)
will no longer match an unvalidated element such as
12
.

Stage 3: Adding a Schema

The output that an XSLT 2.0 stylesheet produces for a given source document can change if you validate the source document before transforming it. This section lists some of the changes that might occur:

• By default, when a source document is validated, whitespace text nodes will be stripped if they appear in elements with element-only content, that is, elements defined in the schema as having a complex type without mixed content. (In fact, this is also likely to happen if the source document is validated against a DTD). In XSLT 1.0, in principle, all whitespace was retained. Some processors such as MSXML, however, were notable for breaking the rules.
  
• Processing a source document using a schema will cause attribute nodes with default values to be added to the tree, and will cause element nodes with default values to acquire a value. These extra nodes will be visible to the XSLT stylesheet.
  
• Because data is now typed rather than untyped, errors may be reported. For example, if an attribute
  birthDate
  is defined in the schema to have type
  xs:date
  , then the expression
  substring(@birthDate,
  1,
  4)
  will fail with a type error, because the
  substring()
  function can be applied only to a string. The remedy is to convert the value to a string explicitly, using the
  string()
  function or a cast.
  
• The results of comparisons may change. The most noticeable effect will be with list-valued elements and attributes, where a comparison (using
  =
  or any of the other general comparison operators) now tests each item in the list of values independently, rather than testing the string value of the containing node as a whole.
  
• The results of sorting may change. For example, if the sort key has type
  xs:dayTime Duration
  , then the values will be compared as durations, not as strings.
  
• Atomizing an element with element-only content is an error. This error can only arise when you have a schema, because without a schema, all elements are considered to have mixed content. An example of an expression that does this is
  contains(invoice,
  “overdue”)
  , which checks for the presence of the string
  overdue
  anywhere in the text of an invoice. To make this work after applying a schema, you need to extract the string value of the invoice explicitly, by writing
  contains(string(invoice), “overdue”)
  .