This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In 19.1 we say the following: "In order to make such expressions streamable, implementations must therefore detect this situation in the construct tree and perform an appropriate rewrite before continuing with the analysis. Specifically, any PathExpr E that is the equivalent expression of some motionless pattern P is replaced by a call on a streamable function that selects the same nodes as would have been selected by E in the absence of streaming restrictions. This function call has a sweep of consuming and a posture of crawling; its static type is that of the original expression E. This makes it eligible to be used, for example, as the argument of the count function." We write "must" in this sentence, but I am not sure how we can enforce this for every (non-streamable) expression E that has an equivalent expression that is a motionless pattern P. I think it is better to relax this requirement, for instance to allow processors to rewrite expressions, or to warn about them and suggest equivalents, but to not make this mandatory.
We discussed this at length at the Prague face to face meeting. Among the points raised: - The paragraph in 19.1 uses the term 'equivalent expression', intended as a reference to 5.6.3, but does not hyperlink it. - The paragraph in 19.1 quoted in the issue description alludes to the inverse of the equivalent-expression rule given in 5.6.3; it would be good to persuade ourselves that that rule is reliably invertible. - It appears at first glance that the rule of 19.1 may handle expressions which cannot be rewritten by the stylesheet author even in principle, since it relies on some notions that are not (readily? or at all?) expressible in XPath, such as the child-or-top pseudo-axis. - Expressions of the form //x/y are included in the subsets of XPath defined for streamable processing by other WGs; it would be unfortunate were our streamability analysis not to accept them without rewriting. - If the algorithm proves elusive or complex, there was some sentiment in the WG (at least one WG member) for relaxing the requirement from a MUST to a MAY; if it proves easy and simple, there seems to be no strong reason to relax it. Different WG members expressed different attitudes towards the prospect of requiring stylesheet authors to rewrite expressions to make them recognizable as streamable; some expected authors to be willing to do this, others felt it was an untenable usability burden. - If the full equivalence algorithm proves problematic, a narrower algorithm that addresses //x/y etc. directly might be a tenable fallback. We'll need to come back to this after further work on the equivalent-expressions algorithm.
Marking this as a duplicate of bug 25160 *** This bug has been marked as a duplicate of bug 25160 ***