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

The XPath 1.0 lexical rules allowed you to write
10div 3
with no space before the
div
; in 2.0, the space is required.

Using an empty sequence as input to an arithmetic operator in 2.0 (in an expression such as
@x+1
, where there is no
x
attribute) gives an empty sequence; in 1.0 it gave NaN.

Serialization Changes

The rules for the serializer have become stricter, which means that the format of the output produced by your chosen processor may need to change, or it might have to report errors where it didn't do so in the past.

One particular rule, which caused a lot of controversy, is that an HTML serializer is now required to report an error if your result tree contains a character in the range 128–159. These characters essentially mean nothing in Unicode; they are permitted in XML, but not in HTML. In practice, if your output contains such a character, the chances are it was copied from the input; and the reason it appeared in the input was probably because Windows codepage 1251 uses characters in this range. If the XML document properly declares that it is using this codepage, then no problem arises, because these characters will be converted to their Unicode equivalents, but if it allows the XML parser to misinterpret the encoding as (say) ISO-8859-1, the conversion to Unicode is done incorrectly, and results in invalid HTML. Because browsers are rather tolerant of invalid HTML, it's quite likely this has been going on for years without anyone noticing, but an XSLT 2.0 serializer will put a stop to it.

The 2.0 rules have also become stricter in regard to the interpretation of
indent=“yes”
. There are more rules now about where the processor is allowed to insert whitespace. The result may be that the pretty printing is not quite as pretty as it used to be.

Stage 2: Setting version=“2.0”

The next stage in your transition to XSLT 2.0 is to switch off backward-compatibility mode by setting the
version
attribute in the

element to
2.0
. This section looks at what changes you should be prepared for when you do this. I'll assume here that you have fixed any problems that arose during stage 1.

The First Node Rule

The most common incompatibilities relate to the dropping of the rule that you can supply a node-set where a single value is expected, and the system will use the first node in the node-set.

In XSLT this arises when a sequence containing more than one value is supplied to: