This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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.
This should have been changed into a spec bug after analysis. Doing that now. Title changed from: [xslt30ts] function-5006
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.
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.
(I mean, my comment#1 misses the mark...)
I have attempted to fix this. However the fix is not tested because Saxon is not yet running this test correctly.