Bug #3944
closed
fn:innermost() expects input sequence to be in document order
100%
Description
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
fn:innermost(($doc1/descendant-or-self::node()/child::node(), $doc2/descendant-or-self::node()/child::node()))
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.
Related issues
Updated by Debbie Lockett about 6 years ago
- Related to Bug #3943: fn:innermost() optimization not working added
Updated by Debbie Lockett about 6 years 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.
Updated by Debbie Lockett about 6 years ago
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in JS Release set to Saxon-JS 1.2.0
Bug fix applied in the Saxon-JS 1.2.0 maintenance release.
Please register to edit this issue
Also available in: Atom PDF Tracking page
.