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( '<font
color="#8B0000">')"
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/
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--