Support #5016
closed
namespace-uri-from-QName does not work on variable created using copy-of
0%
Description
Run the attached xsl on any input xml using Saxon 9.9.1.8. The expected output on 'original' is expected to be the same as on 'variable', however it is not. The namespace-uri-from-QName does not work on the variable, for no good reason.
With Saxon 10.3 the namespace problem is fixed. However, sorting does not seem to work. And for the first $var, which does not ask for any sorting in the code, the output is in a different order than the input.
This is a report form one of our users, that found the problem in regression testing. It did work as expected on older version of oXygen/Saxon.
Files
Updated by Michael Kay almost 3 years ago
This is the output I'm getting with 10.5 (it would be useful to see the output you are getting)
<test xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<select-on-original><!-- content as expected -->
<comp xmlns="urn:hl7-org:v3" xsi:type="IVL_TS" value="2"/>
<comp xmlns="urn:hl7-org:v3" xsi:type="IVL_TS" value="1"/>
<comp xmlns="urn:hl7-org:v3" xsi:type="IVL_TS" value="3"/>
</select-on-original>
<select-on-variable><!-- empty but that is unexpected (namespace predicate problem)-->
<comp xmlns="urn:hl7-org:v3" xsi:type="IVL_TS" value="1"/>
<comp xmlns="urn:hl7-org:v3" xsi:type="IVL_TS" value="2"/>
<comp xmlns="urn:hl7-org:v3" xsi:type="IVL_TS" value="3"/>
</select-on-variable>
<select-on-sorted-variable><!-- empty but that is unexpected (namespace predicate problem) -->
<comp xmlns="urn:hl7-org:v3" xsi:type="IVL_TS" value="2"/>
<comp xmlns="urn:hl7-org:v3" xsi:type="IVL_TS" value="1"/>
<comp xmlns="urn:hl7-org:v3" xsi:type="IVL_TS" value="3"/>
</select-on-sorted-variable>
<select-on-sorted-variable><!-- output is sorted (without namespace predicate)-->
<comp xmlns="urn:hl7-org:v3" xsi:type="IVL_TS" value="2"/>
<comp xmlns="urn:hl7-org:v3" xsi:type="IVL_TS" value="1"/>
<comp xmlns="urn:hl7-org:v3" xsi:type="IVL_TS" value="3"/>
</select-on-sorted-variable>
<select-on-sorted-variableWithSequence><!--output is not sorted unfortunately (namespace predicate works fine) -->
<comp xmlns="urn:hl7-org:v3" xsi:type="IVL_TS" value="2"/>
<comp xmlns="urn:hl7-org:v3" xsi:type="IVL_TS" value="1"/>
<comp xmlns="urn:hl7-org:v3" xsi:type="IVL_TS" value="3"/>
</select-on-sorted-variableWithSequence>
</test>
It looks like the namespace issues have gone with 10.x, so let's focus on the sorting issue. At first sight, it certainly seems surprising that only the second run is sorted on value, when no sorting was requested for that case!
I think the explanation for this lies in the expressions $var//*:comp and $varsorted//*:comp. Because of the use of the '//' operator, these sort nodes into document order. But the nodes are in different trees ($var and $varsorted are sequences of parentless element nodes), and the result of sorting nodes in different trees into document order is undefined.
You can confirm this theory by replacing the operator "//" throughout by "!", in which case the output order is now much more intuitive.
I have a feeling that at some time in the past, Saxon allocated document numbers to parentless elements in order of creation, which had the accidental side-effect of making document order rather more predictable than it is now (and therefore, masking bugs in user code!).
I'll run this again in the debugger to take a more detailed look at what's going on but I'm pretty sure this is the explanation.
Updated by Michael Kay almost 3 years ago
- Status changed from New to In Progress
A little more detail:
The copy operations are creating virtual copies: a virtual copy differs from the original only in using a different document number, so the nodes have distinct IDs even though they share the same underlying memory.
Document IDs for a virtual copy are allocated lazily, when first needed, and they are allocated sequentially. This means that the result of sorting a set of virtual copies into document order will depend on how those virtual copies have been processed in the past -- which can certainly lead to some surprising results.
Updated by Michael Kay almost 3 years ago
- Tracker changed from Bug to Support
- Category set to XSLT conformance
- Status changed from In Progress to Closed
- Assignee set to Michael Kay
I believe the product is working correctly according to the spec, so I am closing this with no action. Feel free to re-open if there is more information.
Please register to edit this issue
.