Stage 1: Backwards Compatibility Mode

It sounds like a contradiction in terms to say that there are incompatibilities that can occur when you are running in backwards compatibility mode enabled (that is, with a stylesheet that specifies «version= "1.0" » ), but it is important to remember that even in this mode, you are using the XPath 2.0 data model rather than the XPath 1.0 data model and that this causes some inevitable differences.

We'll first look at the problems that can potentially occur at the XSLT level, and then at the XPath differences.

The First Node Rule

At the XSLT level, most of the 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.

There are four specific situations where this can arise:

With <xsl:value-of>
With attribute value templates
With sort keys
With the value attribute of <xsl:number>

In all these cases XSLT 1.0 discards any selected node after the first, while XSLT 2.0 normally reports an error. In backwards compatibility mode, however, an XSLT 2.0 processor behaves like an XSLT 1.0 processor.

XPath, in backwards compatibility mode, generally retains the first node rule. This arises for example when calling a function such as contains(): If the first argument is a sequence of nodes, this is normally an error, but in backwards compatibility mode, the function is applied to the string value of the first node.

There has been some discussion about whether processors are actually required to report this error. There is a statement in the XPath specification that a processor is never required to do extra work merely in order to look for errors, and it therefore seems acceptable for a processor to display the first node found without taking the trouble to search to see whether there are any more. This question will probably be clarified in the final specifications.

If your stylesheets do fall foul of this change, it's easy to fix. If the current code is, for example, <xsl:value-of select="//item"/> , change it to <xsl:value-of select="( // item)[1]"/> . Remember to use parentheses where necessary.

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 likely 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 backwards 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 implementer, but it isn't necessarily the Unicode codepoint collation. Nor is it necessarily the same collation as is used by default to support <xsl: sort> . One area where products will necessarily be incompatible is that operators such as «< » and «> » in XPath 2.0, when given two strings or two nodes as their arguments, now do a string comparison rather than trying to convert both operands to numbers . This can catch you out with expressions like:

  <xsl:if test="@price &lt; @margin">

Saxon will give you a warning if it encounters such a construct.

Numeric Precision

XPath 2.0 has (in effect) four numeric data types: double, float, decimal, and integer, whereas XPath 1.0 made do with a single 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. This means that arithmetic that was carried out in floating point with XPath 1.0 may be carried out as decimal or integer arithmetic in XPath 2.0. The main thing you are likely to notice as a result is that you no longer get answers like «1. 000000000054297 », which arose because binary floating point numbers cannot hold all decimal values exactly. It's unlikely that this change will cause any adverse effects. However, if your stylesheets are numerically intensive , then the change in precision of the results could be noticeable.

Very large and very small floating point numbers are now output using scientific notation (or the programmer's variant of scientific notation), for example 1.5E-9. If this output format isn't acceptable, you can use the format-number() function to control the format you want.

There are some changes to the specification of format-number() . In most cases these are tightening up a specification that was previously rather vague in certain areas, but the result of this is that a conformant XSLT 2.0 may do things differently from the way that your favorite 1.0 processor interpreted the specification. XSLT 1.0 defined this function in terms of the Java JDK 1.1 DecimalFormat class, which left many details such as the rounding algorithm unspecified. Later JDK releases tightened this up, but there was no obligation for an XSLT 1.0 processor to implement these clarifications. And in one area the clarification was really formalizing a bug in the implementation: the fact that to a considerable extent, the negative subpicture was ignored when formatting a negative number. XSLT 2.0 has chosen to cut loose from the JDK on this, and now has its own specification for the function, which does not enshrine all the quirks of the Java version.

Other Changes

The previous sections cover the incompatibilities that you are most likely to encounter, but there are one or two other XSLT and XPath changes that are more obscure. There is information on further XPath changes in Appendix C of XPath 2.0 Programmer's Reference.

At the XSLT level you may find that the XSLT processor reports as errors some constructs that were previously ignored. For example, it is now an error to have a mode or priority attribute on an <xsl:template> element with no match attribute. It is also an error for the stylesheet to contain a call on a named template that doesn't exist (even if the call is never executed), and it's an error for <xsl:call-template> to supply a parameter value for a parameter that hasn't been declared on the called template.

You will find a detailed list of further changes in appendixes to the W3C specifications. Most of them are situations where it is extremely unlikely that real stylesheets have been written to depend on the 1.0 behavior, so I won't repeat all these corner cases here.