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

XSLT 2.0 is also stricter about error conditions that can be detected statically. For example, in XSLT 1.0 if an

instruction had a
priority
attribute and no
match
attribute, the
priority
attribute was simply ignored. In 2.0, it is reported as an error. This also applies to inconsistent combinations of attributes on

.

XSLT 1.0 explicitly said that it wasn't an error to use an arbitrary string (for example
!*?$
) as a namespace—that is, there's no requirement that it should be a valid URI. The 2.0 spec wriggles on this point. Element and attribute names are QNames, and QNames are defined in XML Schema as containing an
xs:anyURI
and an
xs:NCName
, so it's no longer possible to say there are no rules about what the namespace can be. However, both the XML Schema spec and the XSLT 2.0 spec leave implementations latitude as to how much checking should be done. As it happens, XML Schema 1.1 is moving in the direction of allowing any string to be used as an
xs:anyURI
value.

Comparing Strings

In XSLT 1.0 testing for equality between two strings performed a strict comparison of the codepoints of the characters in the two strings. There was no flexibility to treat
“XML”
and
“xml”
as being equal. Sorting, however, was left very much up to the implementation: two different products would probably sort the same set of strings differently. There was no
<
operator to compare strings, and no
min()
or
max()
function.

This changes significantly in XSLT 2.0 and XPath 2.0, though the amount of backward incompatibility depends to a considerable extent on choices made by the vendor. The
=
operator, when comparing two strings, now uses the default collation. How the default collation is defined is up to the implementor, but it isn't necessarily the Unicode codepoint collation. Nor is it necessarily the same collation as is used by default to support

.

Sort keys defined using

(in the absence of
data-type=“text”
) are now compared using their actual data type, rather than being converted to strings. This will only affect you in the unlikely event that your stylesheet defines a numeric key (for example,
@length mod 100
) and you actually wanted it to be sorted as a string rather than a number.

Numeric Formats

XPath 2.0 has (in effect) four numeric data types: double, float, decimal, and integer, whereas XPath 1.0 made do with one type, double. Literals that were interpreted as doubles in XPath 1.0 (such as
3.5
or
17
) may be interpreted as decimals or integers in XPath 2.0. However, when backward-compatibility mode is selected, all arithmetic is still done in double-precision floating point.