This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 29958 - [xslt30ts] function-5006
Summary: [xslt30ts] function-5006
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 Test Suite (show other bugs)
Version: Candidate Recommendation
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Abel Braaksma
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-10-24 15:45 UTC by Michael Kay
Modified: 2017-01-28 22:14 UTC (History)
1 user (show)

See Also:


Attachments

Description Michael Kay 2016-10-24 15:45:16 UTC
I believe this test case is not streamable.

Consider the path expression

sf:deep-descent(section[1])/p[2]

The function call sf:deep-descent(section[1]) is crawling and consuming.

"The provisional posture of the expression is the posture of the right-hand operand, assessed with a context posture and type set to the posture and type of the left-hand operand" - the combination of crawling with the child axis gives roaming.

The expression is not a scanning expression, so the posture is the provisional posture.
Comment 1 Abel Braaksma 2016-10-25 00:33:50 UTC
This looks like a case not properly covered by rule 19.8.8.8, item 4.

The point of this rule is that if the rh-side always selects a singleton node, there is no possibility of overlap, hence the restriction for this rule with numeric predicates.

(some crawling expression)/axis-step[numeric-expression]

-- where axis-step is child/descendant/descendant-or-self

result should be striding. This is somewhat surprising, but I believe it is correct and we may need to reflect this in the rules.
Comment 2 Abel Braaksma 2016-11-03 15:55:24 UTC
This should have been changed into a spec bug after analysis. Doing that now.

Title changed from: [xslt30ts] function-5006
Comment 3 Michael Kay 2016-11-03 17:58:28 UTC
I can't see how 19.8.8.8 rule 4 is relevant. That rule says that if E is crawling then E[N] is striding provided N evaluates to a simple number. This case is quite different.

I'm not even sure what you mean by the "rh-side". The rule is about axis expression filtered by a numeric predicate.

The current rules say that this expression is crawling and we would need substantial new machinery to change that; I think the test is simply wrong.
Comment 4 Abel Braaksma 2016-11-05 13:41:12 UTC
I apologize, I misunderstood my own suggestion in comment#1 and my comment#2 completely misses the mark.

I have committed a fix for this test, but I found myself confused about scanning expressions and am not 100% certain the current fix is sound, so I'm leaving this open for now so that others can have a look.

Changing it back to a test bug.
Comment 5 Abel Braaksma 2016-11-05 13:41:55 UTC
(I mean, my comment#1 misses the mark...)
Comment 6 Michael Kay 2017-01-28 22:14:49 UTC
I have attempted to fix this. However the fix is not tested because Saxon is not yet running this test correctly.