Bug #5131
closed
XSLT command line tool has different result with <xsl:global-context-item use="absent"/>
Category:
XSLT conformance
Fix Committed on Branch:
10, trunk
Fixed in Maintenance Release:
Description
XSLT command line tool result should be the same when <xsl:global-context-item use="absent"/> is specified.
The only difference is that with <xsl:global-context-item use="absent"/> the source tree is not built prior to invoking applyTemplates. Otherwise, by default, the tree is built and added to the global context prior to invoking applyTemplates.
How the source XML is pre-processed should not affect the result of the XSLT transformation.
Please refer to attached files.zip and matching command lines below:
java -jar /tmp/saxon9he.jar -s:datastore.xml -xsl:orig.xsl -o:orig_output.xml -t -T > orig_debug.log 2>&1
java -jar /tmp/saxon9he.jar -s:datastore.xml -xsl:nocontext.xsl -o:nocontext_output.xml -t -T > nocontext_debug.log 2>&1
saxon9he.jar is taken from https://sourceforge.net/projects/saxon/files/Saxon-HE/9.9/SaxonHE9-9-1-8J.zip/download
files.zip contains the following:
saxonica_ticket/
├── datastore.xml
├── nocontext_debug.log
├── nocontext_output.xml
├── nocontext.xsl
├── orig_debug.log
├── orig_output.xml
├── orig.xsl
└── README
Files
It seems to me that an error https://www.w3.org/TR/xpath-30/#ERRXPDY0002 should be raised if the context item has been declared to be absent and there is use of a global variable (e.g. add_out-interface-usages
) having an <xsl:copy>
instruction inside . Let's see what Michael says.
Just clarifying my description above where the end of lines were swallowed:
java -jar /tmp/saxon9he.jar -s:datastore.xml -xsl:orig.xsl -o:orig_output.xml -t -T > orig_debug.log 2>&1
where orig_output.xml contains
<out-interface-usages>
<interface-usages>subtended-node-port</interface-usages>
</out-interface-usages>
java -jar /tmp/saxon9he.jar -s:datastore.xml -xsl:nocontext.xsl -o:nocontext_output.xml -t -T > nocontext_debug.log 2>&1
where nocontext_output.xml contains
<out-interface-usages/>
files.zip contains the following:
saxonica_ticket/
├── datastore.xml
├── nocontext_debug.log
├── nocontext_output.xml
├── nocontext.xsl
├── orig_debug.log
├── orig_output.xml
├── orig.xsl
└── README
The only difference is that nocontext.xsl contains <xsl:global-context-item use="absent"/>.
As such, I would expect the output of the XSLT to be the same or a more graceful behaviour, with error or not.
The spec states in §11.9.1
[ERR XTTE0945] It is a type error to use the xsl:copy
instruction with no select attribute when the context item is absent.
and Saxon is failing to report this error. Instead, xsl:copy
is returning an empty sequence in this situation (i.e. it is a no-op).
In fact there are two opportunities to detect the type error, at compile time and at run time, and Saxon is missing both.
In XSLGlobalVariable.initializeBinding()
it should check for the existence of an <xsl:global-context-item>
declaration when allocating a static type to the contextItemStaticInfo object.
In Copy.processLeavingTail
it should report a type error if the context item is null.
Thanks for the prompt response. It will help us in improving our XSL to prevent these issues to start with.
- Category set to XSLT conformance
- Status changed from New to Resolved
- Assignee set to Michael Kay
- Priority changed from Low to Normal
- Applies to branch 10, 11 added
- Applies to branch deleted (
9.9)
- Fix Committed on Branch 10, trunk added
Added test case global-cxt-item-013 to catch the static case.
Test case copy-4308 is already there to catch the dynamic case, according to the test description: but in fact the error is being detected statically. Indeed, the test is identical to copy-4307 which is supposed to catch it statically (and does so). I've rewritten this test.
Fixed on the 10 and 11 branches.
- % Done changed from 0 to 100
- Fixed in Maintenance Release 11.1 added
- Platforms .NET added
Bug fix applied in the Saxon 11.1 release.
Leaving bug as resolved until fix applied to the Saxon 10 maintenance release.
- Status changed from Resolved to In Progress
Reopened because the revised test copy-4308 is currently failing on the 10.x branch (specifically, it is not detecting the error). I've checked that the patches were correctly applied.
- Status changed from In Progress to Resolved
The fix for the bytecode case had not been retrofitted to the 10.x branch. Now fixed.
- Status changed from Resolved to Closed
- Fixed in Maintenance Release 10.7 added
- Fixed in Maintenance Release deleted (
11.1)
Bug fix applied in the Saxon 10.7 maintenance release.
- Fixed in Maintenance Release 11.1 added
Please register to edit this issue
Also available in: Atom
PDF