29958 2016-10-24 15:45:16 +0000 [xslt30ts] function-5006 2017-01-28 22:14:49 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Test Suite Candidate Recommendation PC All RESOLVED FIXED P2 normal --- 1 mike abel.online abel.braaksma public-qt-comments oldest_to_newest 127943 0 mike 2016-10-24 15:45:16 +0000 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. 127947 1 abel.braaksma 2016-10-25 00:33:50 +0000 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. 128036 2 abel.braaksma 2016-11-03 15:55:24 +0000 This should have been changed into a spec bug after analysis. Doing that now. Title changed from: [xslt30ts] function-5006 128040 3 mike 2016-11-03 17:58:28 +0000 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. 128069 4 abel.braaksma 2016-11-05 13:41:12 +0000 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. 128070 5 abel.braaksma 2016-11-05 13:41:55 +0000 (I mean, my comment#1 misses the mark...) 128421 6 mike 2017-01-28 22:14:49 +0000 I have attempted to fix this. However the fix is not tested because Saxon is not yet running this test correctly.