Saxon

Legacy ID: #7766001 Legacy Poster: Michael Kay (mhkay)

If the stylesheet specifies version="1.0" then it will run in backwards compatibility mode, which will solve many of these problems, but that doesn't mean it's a perfect emulation of an XSLT 1.0 processor, let alone a perfect emulation of Saxon 6.5. "Unsupported html version: 1.0" - that looks like a stylesheet error that Saxon 6.5 failed to detect or report. "An attribute node cannot be created after the children of the containing element": I'm a bit puzzled by that one, this should be an error under both releases. According to the XSLT 1.0 spec it's a recoverable error, so it might be that Saxon 6.5 was recovering from it (but I would have expected a warning at least). "invalid argument to sum() that is not numeric": I would have expected 1.0 compatibility mode to sort this, unless it's something really bizarre.

Legacy ID: #7766229 Legacy Poster: David Lee (daldei)

The stylesheet version is set to "1.0" yet these things still happen. If you are interested I can send you a zip of all the included XSL files and a sample XML which is supposed to process, but only works in saxon 6.5 ... but only if you want to, I've since hacked the thing to death for my own purposes and now it runs (but it doesn't resemble the original - I'm trying to learn XSLT ...) I am curious on the results though because you've previously indicated that Saxon 9.x should run 'most' XSLT 1.0 stylesheets unchanged. For that reason I've neglected to attempt to provide explicit xslt 1.0 support in xmlsh. This example, however, seems to demonstrate a real world (and probably really important, seeing as its a published document from the FDA) case where that is not so. So I'm interested in the final conclusions on if I need to support saxon 6.5 in addition to 9.x in xmlsh for cases like this. (it would be painful though as managing the classpath for both products combined might be a tad tricky).

Legacy ID: #7766316 Legacy Poster: Michael Kay (mhkay)

Yes, I'd certainly be interested to have a runnable test case that shows what these problems really are. It's all useful knowledge to share with the community. I'm afraid that saying that "most" stylesheets will run without change may be slightly wishful thinking. It probably applies to stylesheets that are portable across XSLT 1.0 processors, but it might not apply to stylesheets that are exploit Saxon-specific features. And of course it depends on size: if on average one line in 2000 needs changing, then most stylesheets under 1000 lines will be OK, whereas most stylesheets over 5000 lines won't; and when you get to 50K lines, the cost of transition starts to become quite significant.

Legacy ID: #7766495 Legacy Poster: Michael Kay (mhkay)

Thanks for sending the repro. Saxon 6.5 reports numerous instances of "Recoverable error at xsl:attribute on line 803 of file:/e:/users/lee/Stylesheet/spl-common.xsl: Cannot write an attribute node when no element start tag is open" In XSLT 1.0 this was a recoverable error, and the recovery action was to ignore the attribute (it simply wasn't written). (Processors have the option to treat recoverable errors as fatal, or to take the recovery action.) XSLT 2.0 changed this error to be non-recoverable (i.e. always fatal). Many of the recoverable errors were changed in this way, as part of a general move to make the language a bit more robust, and also to make stylesheets more portable across processors. So a stylesheet with this error was never portable under XSLT 1.0, and it's a sign of pretty poor programming to ignore a warning message like this. This incompatibility is documented in the spec: see http://www.w3.org/TR/xslt20/#incompatibility-without-schema clause 6. So it's a spec issue rather than a Saxon issue. It can be a bit difficult to diagnose this error, even with the -T trace option. The problem is this code at line 1210 of common.xsl:

<xsl:if test="@ID"> </xsl:if> <xsl:call-template name="styleCodeAttr"> which creates an <a> element, and then calls the template styleCodeAttr which create class and style attributes for the <p> element. This clearly isn't going to work: the attributes should be created first. So I think this is case where the incompatibility has justified itself: it has detected a logic error in the stylesheet which XSLT 1.0 allowed through.

Legacy ID: #7766529 Legacy Poster: Michael Kay (mhkay)

I've taken the opportunity to improve the diagnostics for the condition. It turns out the location (line number / module) of the instruction that generated the most recent startElement event is available at the time the error is detected, which means it's not difficult to add to the message "Most recent element start tag was output at line 1213 of module spl-common.xsl". In some cases this will be the offending child element, in other cases (where the attribute is preceded only by text) it will be the parent element.

Legacy ID: #7766531 Legacy Poster: David Lee (daldei)

Thanks mike. I can see its the American Tax Dollars put to good use :) I wonder if there is a good way to report these kinds of problems to the FDA in a way that would actually be productive (instead of where my usual letters to congressmen go) I appreciate your diagnosis, it was as I expected (but not as I hoped). Did you see what the problem with the sum() was ? I suspect thats 'bad coding' as well that XSLT 1.0 just ignored.

Legacy ID: #7766561 Legacy Poster: Michael Kay (mhkay)

I haven't managed to replicate the problem with sum(). How did you get it?

Legacy ID: #7766566 Legacy Poster: David Lee (daldei)

Using the files I sent you, change spl.xsl only to set the html version to 4.0 Run using Saxon 9.1.0.5 (I'm using Stylus Studio for this test) I get the following error Warning: on line 88 of file:///c:/Work/EPOCRA%7E1/DATASO%7E1/SPL/saxonbug/spl-common.xsl: The attribute axis starting at a document node will never select anything at: file:///c:/Work/EPOCRA%7E1/DATASO%7E1/SPL/saxonbug/spl-common.xsl 1439 java.lang.RuntimeException: Error: on line 1439 of file:///c:/Work/EPOCRA%7E1/DATASO%7E1/SPL/saxonbug/spl-common.xsl: FORG0006: Input to sum() contains a value that is neither numeric, nor a duration at com.exln.stylus.CSaxon8Driver.doProcessing(CSaxon8Driver.java:281) at com.exln.stylus.CProcessorDriver.process(CProcessorDriver.java:104) spl-common.xsl (1439, 1) Error: on line 1439 of file:///c:/Work/EPOCRA%7E1/DATASO%7E1/SPL/saxonbug/spl-common.xsl: FORG0006: Input to sum() contains a value that is neither numeric, nor a duration

Legacy ID: #7766581 Legacy Poster: Michael Kay (mhkay)

This is what I get with 9.1.0.5 (and all other releases): Saxon 9.1.0.5J from Saxonica Java version 1.6.0_17 Warning: at xsl:transform on line 26 column 138 of spl.xsl: Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor Warning: on line 88 of spl-common.xsl: The attribute axis starting at a document node will never select anything Warning: on line 1460 of spl-common.xsl: Creating an attribute here will fail if previous instructions create any children Stylesheet compilation time: 772 milliseconds Processing file:/e:/users/lee/test.xml Building tree for file:/e:/users/lee/test.xml using class net.sf.saxon.tinytree.TinyBuilder Tree built in 27 milliseconds Tree size: 3789 nodes, 56763 characters, 2179 attributes Loading net.sf.saxon.event.MessageEmitter Building tree for file:/e:/users/lee/Stylesheet/plr-sections.xml using class net.sf.saxon.tinytree.TinyBuilder Tree built in 1 milliseconds Tree size: 152 nodes, 1135 characters, 80 attributes Error on line 803 of spl-common.xsl: XTDE0410: An attribute node (class) cannot be created after the children of the containing element at xsl:call-template name="styleCodeAttr" (file:/e:/users/lee/Stylesheet/spl-common.xsl#1215) at xsl:apply-templates (file:/e:/users/lee/Stylesheet/spl-common.xsl#1642) processing /document/component[1]/structuredBody[1]/component[6]/section[1]/excerpt[1]/highlight[1]/text[1]/paragraph[1] at xsl:apply-templates (file:/e:/users/lee/Stylesheet/spl-common.xsl#1491) processing /document/component[1]/structuredBody[1]/component[6]/section[1]/excerpt[1]/highlight[1]/text[1]/paragraph[1] at xsl:apply-templates (file:/e:/users/lee/Stylesheet/spl-common.xsl#1491) processing /document/component[1]/structuredBody[1]/component[6]/section[1]/excerpt[1]/highlight[1]/text[1] at xsl:apply-templates (file:/e:/users/lee/Stylesheet/spl-common.xsl#556) processing /document/component[1]/structuredBody[1]/component[6]/section[1]/excerpt[1]/highlight[1] at xsl:apply-templates (file:/e:/users/lee/Stylesheet/spl-common.xsl#304) processing /document/component[1]/structuredBody[1]/component[6]/section[1]/excerpt[1] at xsl:for-each (file:/e:/users/lee/Stylesheet/spl-common.xsl#302) processing /document/component[1]/structuredBody[1]/component[6]/section[1]/excerpt[1] at xsl:call-template name="highlights" (file:/e:/users/lee/Stylesheet/spl-common.xsl#78) Transformation failed: Run-time errors were reported Sure it's the same source document? I would expect the error you are seeing if there's a non-numeric colspan attribute in the source document (which there isn't in this sample, I think). That's another case where XSLT 2.0 has become a bit more finicky: 1.0 returned NaN as the result of the sum(), 2.0 throws a dynamic error. Again, NaN doesn't seem like a useful result.

Legacy ID: #7766594 Legacy Poster: David Lee (daldei)

Yes its the same document, but I see what I did. I had the "Schema Aware" button checked. That is what is triggering the sum errors I think. Turning off schema aware, then I get back to the attribute after element data error.