[Bug 25316] [XSLT 3.0] Streamabilty and numeric predicates


--- Comment #5 from Michael Kay <mike@saxonica.com> ---
Some observations:

>1) I think this new rule, and the existing rule, has an error.... Because the result is a single node, the resulting posture should be striding.

Yes, you are right.

2) "... and consuming". I can't think of a crawling expression that is
motionless, it could happen in xsl:for-each, but there a crawling expression
cannot be the focus setting expression.

Yes. There's an underlying problem that posture and sweep are not orthogonal.
It would be a good idea to have a chart somewhere that shows which combinations
are possible.

3) We do allow position() in a predicate, except that than the result of
B[position()] is crawling (this follows from the next rule in that section).

Not sure of your point?

4) "that has F as its focus-setting container" >> I think you mean "that has B
as its focus-setting container. F already includes P, so I don't think the
whole expression can be its own focus-setting container.

B isn't a container of the predicate, so it can't be the focus-setting
container. The terminology might not be ideal, but I think we are using the
term the way it is defined.

5) "other than last();" >> the last() function is already prohibited in a
filter expression, unless in a nested filter expression with climbing posture,
but these rules rule other path expressions out.

Not sure of your point...

6) We have a rule under (axis steps) that is almost the same:

"4. If the context posture is striding, and the axis is descendant or
descendant-or-self, and there is a predicate in the PredicateList that is
either a numeric literal or a variable reference whose static type is a subtype
of U{xs:decimal, xs:double, xs:float} (for example, descendant::title[1]), then
striding and consuming;"

Should we apply these new rules there as well (or reference it to have them in
one place)?

Yes, we should apply the same thinking to that rule. Sorry I missed that one.

You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 15 July 2014 22:44:38 UTC