fn:innermost() expects input sequence to be in document order
The converted QT3 tests fn-innermost-053 and fn-innermost-054 fail for SEFs generated by 9.9, but pass for SEFs generated by 9.8.
fn-innermost-053 tests the XPath
fn:innermost( ($doc1//node(), $doc2//node()) )
in the expanded form
In the 9.8 SEF, the input to the fn:innermost call is in a global variable, and the paths have been optimised to
$doc1/descendent::node(), etc. But this is not the case for the 9.9 SEF.
This means that for 9.9 the sequence supplied to the fn:innermost call is not necessarily in document order. The Saxon-JS code (in CoreFn.js) for processing fn:innermost does not do any sorting into document order, but the processing algorithm relies on the sequence being ordered.
#2 Updated by Debbie Lockett 4 months ago
- Status changed from In Progress to Resolved
- Fix Committed on JS Branch 1.0, Trunk added
Fix in CoreFn.js, innermost: check for presorted 'p' flag, and if not presorted then first sort input into document order. (Refer to code in outermost which already does this.)
Patch committed on Saxon-JS 1 and trunk branches.
Please register to edit this issue