Bug #3944
closedfn: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
Please register to edit this issue
Also available in: Atom PDF Tracking page