RE: [xsl] Some Pointers on XSLT 2.0 vs. 1.0 and for Using XSLT 2.0 on the Web

["Michael Kay" <mike@xxxxxxxxxxxx>]

> The basic issue is that XSLT 2.0 and XPath 2.0 appear to be a 
> bit more strict than XSLT 1.0.  This has a number of ramifications.
> 
> (1)  Some of my XSL code inadvertently contained \ as a "file 
> separator"
> (using the Java term) in file paths.  This was not a problem 
> on Windows, of course, where paths use backslashes, but it 
> caused Saxon errors on Linux, which was of course expecting 
> /.  It seems that XSLT 1.0 "forgave" the error on Linux 

This is a processor issue, not a language issue. There's more than one XSLT
1.0 processor, and you haven't said which one you were using. The language
rules for accepting URIs have probably changed in the direction of being
more tolerant, to reflect the fact that many processors were allowing things
that weren't strictly speaking URIs.

> (2)  Another problem was that my XSL code contained calls to the XPath
> concat() function with just one argument.  Such calls were 
> used to render HTML code that would otherwise not be 
> well-formed.  

>       <xsl:value-of select="concat( '&lt;font 
> color=&quot;#8B0000&quot;&gt;')"

That's definitely an error in both XSLT 1.0 and 2.0. (I argued in favour of
allowing it in 2.0, because it's a pointless restriction, but I lost the
vote).

The concat() call here serves no useful function. You can replace
concat('x') by 'x'.

> 
> Note: The following will *not* work because the XSL would not 
> be well-formed and therefore the stylesheet would not compile:
> 
>     <xsl:if test="date/@color">
>       <font color="#8B0000">
>     </xsl:if>
>       ... do some fancy XSLT stuff here ...
>     <xsl:if test="date/@color">
>       </font>
>     </xsl:if>
> 
This is awful code whether you are using 1.0 or 2.0 - now would be a good
time to find out how to write this "properly". Usually one sees
disable-output-escaping used as a workaround because grouping in XSLT 1.0 is
perceived as being difficult; well, it's easier in XSLT 2.0 so any such
excuse has no disappeared.

> (3)  Another error that XSLT 1.0 forgave and XSLT 2.0 did not 
> is that I inadvertently put a test attribute on an xsl:choose 
> element.  That was obviously a mistake, but I never caught it 
> because XSLT 1.0 didn't complain.

Again, there's no language difference. You were using an XSLT 1.0 processor
that didn't implement the language correctly, and you have moved to a 2.0
processor that does.

> The more strict XSLT 2.0, however, wouldn't compile the stylesheet.
> 
> (4)  When working on the web, problems with an XSLT 
> stylesheet cause the web page to display something like:
> 
>      javax.xml.transform.TransformerConfigurationException: 
>      Failed to compile stylesheet. 6 errors detected.  
> 
> This is not very helpful to developers because there is no 
> indication as to where the errors are.  As it turns out, the 
> full error messages are written to the stdout_YYYYMMDD.log 
> file in the Tomcat logs directory.  One always has access to 
> that directory on a Windows system, but on Linux, one may not.

Again this is a processor issue - more accurately, it is an application/API
issue. It's easy to get the compile-time errors to appear on the browser
screen if that's where you want them, but the way of doing it might vary
from one product to another.
> 
> (5)  One last small thing about what you see above.  When 
> using XSLT 1.0 stylesheets with saxon9.jar on the web, the 
> warning shown above:
> 
>      Warning: at xsl:stylesheet on line 12 column 80 of 
> common-lecs.xsl:
>        Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor
> 
> does not show up on the web page, so I didn't have to go 
> through and change all the xsl:stylesheet declarations on my website:
> 
>      <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
> version="1.0">

The requirement for processors to issue this warning was another thing that
I voted against. It has the wrong effect: people blindly change the version
attribute to 2.0, perhaps in a global edit, just to get rid of the warning.
You shouldn't do this unless you have carefully understood the different
rules for backwards compatibility that apply when you set version="2.0"
versus version="1.0".

> 
> The bottom line for readers who would like to upgrade to XSLT 
> 2.0 but have an understandable fear that their websites or 
> applications will no longer work is that our experience is 
> that XSLT 2.0 appears to be fully backward compatible with 
> XSLT 1.0 except for a few more restrictive rules.

Yes, and I think your experience matches others - that you are more likely
to be hit by product issues than by language issues. In this case most of
the issues you encountered were because your application was relying on
non-conformant behaviour by your XSLT 1.0 product. It's also very common to
find that you are relying on behaviour that is not non-conformant, but is
explicitly implementation-defined or implementation-dependent (for example,
extension functions). Most of the issues you describe would be exactly the
same if you had moved to a different XSLT 1.0 processor.

Michael Kay
http://www.saxonica.com/