This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
There is an error (or at any rate, a serious limitation) in the streamability rules for relative path expressions. The spec (section 19.3.7, RelativePathExpr [35]) says that if the first step of the path expression is motionless, then the path expression is motionless. Consider the expression ./x, or equivalents such as (. treat as node())/x. The syntactic context of the LHS of "/" is a navigation context; "." in a navigation context is free-ranging; therefore ./x is free-ranging.
Disucssed by the WG today. Needs further investigation to see if we can identify a solution. Alternatively, can we live with the restriction that such expressions are not guaranteed streamable?
I believe the problem can be fixed by adding another streamability rule for RelativePathExpr after: If the first StepExpr is motionless, then motionless namely if either operand is a ContextItemExpr, or an AxisStep using the self axis in which all predicates are motionless, then the streamability of the other operand.
I propose the following text. In 19.3.7, Classifying expressions, change the entry for RelativePathExpr [35] as follows: Change the first paragraph to: The RelativePathExpr is first preprocessed as follows: (a) Any '//' pseudo-operator is expanded to '/descendant-or-self::node()/' (b) The expression tree is written in such a way that '/' is a binary operator, for example a/b/c becomes (a/b)/c. The following rules then apply to a RelativePathExpr that has '/' as its operator, with two operands. The streamability is the first of the following that applies: 1. If either operand is a ContextItemExpr (".") or an AxisExpression using the self axis, optionally followed (in either case) by one or more motionless predicates, then the streamability of the other operand. 2. (existing rule 1, et seq, unchanged)
The proposed text was accepted (2 May 2013) and has been incorporated in the spec.