Project

Profile

Help

Bug #3944

closed

fn:innermost() expects input sequence to be in document order

Added by Debbie Lockett about 6 years ago. Updated about 6 years ago.

Status:
Closed
Priority:
Normal
Category:
-
Sprint/Milestone:
-
Start date:
2018-10-03
Due date:
% Done:

100%

Estimated time:
Applies to JS Branch:
1.0, Trunk
Fix Committed on JS Branch:
1.0, Trunk
Fixed in JS Release:
SEF Generated with:
Platforms:
Company:
-
Contact person:
-
Additional contact persons:
-

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

Related to Saxon - Bug #3943: fn:innermost() optimization not workingClosedMichael Kay2018-10-03

Actions

Please register to edit this issue

Also available in: Atom PDF Tracking page