Project

Profile

Help

Bug #5131

closed

XSLT command line tool has different result with <xsl:global-context-item use="absent"/>

Added by Frederic Guilbeault about 3 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
XSLT conformance
Sprint/Milestone:
-
Start date:
2021-10-18
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
10, 11
Fix Committed on Branch:
10, trunk
Fixed in Maintenance Release:
Platforms:
.NET, Java

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

files.zip (6.48 KB) files.zip Frederic Guilbeault, 2021-10-19 00:04
Actions #1

Updated by Martin Honnen about 3 years ago

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.

Actions #2

Updated by Frederic Guilbeault about 3 years ago

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.

Actions #3

Updated by Michael Kay about 3 years ago

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.

Actions #4

Updated by Frederic Guilbeault about 3 years ago

Thanks for the prompt response. It will help us in improving our XSL to prevent these issues to start with.

Actions #5

Updated by Michael Kay about 3 years ago

  • 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.

Actions #6

Updated by O'Neil Delpratt almost 3 years ago

  • % 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.

Actions #7

Updated by O'Neil Delpratt almost 3 years ago

Leaving bug as resolved until fix applied to the Saxon 10 maintenance release.

Actions #8

Updated by Michael Kay over 2 years ago

  • 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.

Actions #9

Updated by Michael Kay over 2 years ago

  • Status changed from In Progress to Resolved

The fix for the bytecode case had not been retrofitted to the 10.x branch. Now fixed.

Actions #10

Updated by Debbie Lockett over 2 years ago

  • 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.

Actions #11

Updated by Debbie Lockett over 2 years ago

  • Fixed in Maintenance Release 11.1 added

Please register to edit this issue

Also available in: Atom PDF