Upgrading XSLT 1.0 to XSLT 2.0

What is involved in upgrading from XSLT 1.0 to 2.0?
1 - What are the possible reasons for upgrading?
2 - What are the possible reasons for NOT upgrading?
3 - And finally, what are the steps to upgrading?

I'm hoping for an executive summary--the short version :)

Solution 1:

What is involved in upgrading from XSLT 1.0 to 2.0?

1 - What are the possible reasons for upgrading?

If you are an XSLT programmer you'll benefit largely from the more convenient and expressive XSLT 2.0 language + XPath 2.0 and the new XDM (XPath Data Model).

You may want to watch this XSLT 2.0 Pluralsight course to get firm and systematic understanding of the power of XSLT 2.0.

You have:

• Strong typing and all XSD types available.

• The ability to define your own (schema) types.

• the XPath 2.0 sequence type that doesn't have any counterpart (simply is missing) in XPath 1.0.

• The ability to define and write functions in pure XSLT -- the xsl:function instruction.

• Range variables in XPath expressions (the for clause).

• Much better and more powerful string processing -- XPath 2.0 supports regular expressions in its tokenize(), matches() and replace() functions.

• Much better and more powerful string processing -- XSLT 2.0 support for regular expressions -- the xsl:analyze-string, xsl:matching-substring and xsl:non-matching-substring new XSLT instructions.

• More convenient, powerful and expressive grouping: the xsl:for-each-group instruction.

• A lot of new, very powerful XPath 2.0 functions -- such as the functions on date, time and duration, just to name a few.

• The new XPath operators intersect, except, is, >>, <<, some, every, instance of, castable as, ..., etc.

• The general XPath operators >, <, etc. now work on any ordered value type (not only on numbers as in XPath 1.0).

• New, safer value comparison operators: lt, le, eq, gt, ge, ne.

• The XPath 2.0 to operator, allowing to have xsl:for-each select="1 to $N"

These, and many other improvements/new features significantly increase the productivity of any XSLT programmer, which allows XSLT 2.0 development to be finished in a small fraction of the time necessary for developing the same modules with XSLT 1.0.

Strong typing allows many errors to be caught at compile time and to be corrected immediately. For me this strong type-safety is the biggest advantage of using XSLT 2.0.

2 - What are the possible reasons for NOT upgrading?

• It is often possible, reasonable and cost-efficient to leave existing, legacy XSLT 1.0 applications untouched and to continue using them with XSLT 1.0, while at the same time developing only new applications using XSLT 2.0.

• Your management + any other non-technical reasons.

• Having a lot of legacy XSLT 1.0 applications written in a poor style (e.g. using DOE or extension functions that now need to be re-written and the code refactored).

• Not having available an XSLT 2.0 processor.

3 - And finally, what are the steps to upgrading?

• Change the version attribute of the xsl:stylesheet or xsl:transform element from "1.0" to "2.0".

• Remove any xxx:node-set() functions.

• Remove any DOE.

• Be ready for the surprise that xsl:value-of now outputs not just the first, but all items of a sequence.

• Try to use the new xsl:sequence instruction as much as possible -- use it to replace any xsl:copy-of instructions; use it instead of xsl:value-of any time when the type of the output isn't string or text node.

• Test extensively.

• When the testing has verified that the code works as expected, start refactoring (if deemed necessary). It is a good idea to declare types for any variables, parameters, templates and functions. Doing so may reveal new, hidden errors and fixing them increases the quality of your code.

• Optionally, decide which named templates to rewrite as xsl:function.

• Decide if you still need some extension functions that are used in the old version, or you can rewrite them easily using the new, powerful capabilities of XSLT.

Final remarks: Not all of the above steps are necessary and one can stop and declare the migration successful on zero bug testing results. It is much cleaner to start using all XSLT 2.0/XPath 2.0 features in new projects.

Solution 2:

Dimitre's answer is very comprehensive and 100% accurate (as always) but there is one point I would add. When upgrading to a 2.0 processor, you have a choice of leaving the version attribute set to "1.0" and running in "backwards compatibility mode", or changing the version attribute to "2.0". People often ask which approach is recommended.

My advice is, if you have a good set of tests for your stylesheets, take the plunge: set version="2.0", run the tests, and if there are any problems, fix them. Usually the problems will be code that was never quite right in the first place and only worked by accident. But if you don't have a good set of tests and are concerned about the reliability of your workload, then leaving version="1.0" is a lower-risk approach: the processor will then emulate all the quirks of XSLT 1.0, such as xsl:value-of ignoring all but the first item, and the strange rules for comparing numbers with strings.