- From: Michael Kay <mike@saxonica.com>
- Date: Wed, 7 Dec 2016 12:01:56 +0000
- To: Public XSLWG <public-xsl-wg@w3.org>
>ACTION 2016-11-17-005: MK to rewrite proposal for bug 29983, taking comments 4 and following into account.
1. The specification currently uses and explains the term "equivalent expression" but without a formal termdef.
<ASIDE>
There's a quirk in the definition: the equivalent expression to the pattern A/B is not child::A/child::B, but child-or-top::A/child::B. However, we say in 19.8.8.7 that we are concerned with the path expression after expansion of abbreviations, so the question is "is child::A/child::B the equivalent expression of some pattern?" and the answer is yes: it is not the equivalent expression of A/B, but it is the equivalent expression of child::A/child::B. So it turns out we can ignore this quirk after all.
</ASIDE>
Turn the current definition into a termdef so that we can link to it.
(This requires a bit of editorial rearrangement of the text. The current definition is
The equivalent expression to a Pattern is the XPath expression that takes the same lexical form as the Pattern as written, with the following adjustment:
together with the (single!) bullet point that follows, which describes the adjustments. But I don't propose any substantive change here).
2. The term "motionless pattern" is used often enough that it is worth having a definition we can link to (in 19.8.10):
[Definition: A *motionless pattern* is a *pattern* whose *posture* is *motionless*.]
3. In 19.8.8.7, change list item 2 to read:
If the provisional posture is roaming, and if the expression is the *equivalent expression* of some *motionless pattern*, then the actual posture of the expression is as follows:
* If the static type of the expression contains U{element} then its posture is crawling.
* Otherwise, its posture is striding
followed immediately by the Note about scanning expressions, rewritten as follows:
An example of a relative path expression that is the equivalent expression of a motionless pattern is the expression descendant::section/child::para. The problem with such an expression is that a nested loop evaluation strategy (for $s in descendant::section return $s/child::head) does not necessarily deliver nodes in document order (consider the input <section><section><para/></section><para/></section>, where the ordering of para elements is not the same as the ordering of their parent sections: the second para is a child of the first section). In consequence, the nested loop strategy is not a viable strategy for streaming.
But there is a different strategy for evaluating such an expression, which is to scan all descendants in document order, looking for nodes that match the motionless pattern $V/descendant::section/child::para, where $V is the context node for evaluation of the relative path expression. This strategy considers each node in order without sorting, and is therefore streamable.
For a relative path expression to be guaranteed streamable under this rule, it must satisfy two conditions: (a) it must be the equivalent expression to some pattern P (which essentially means that the syntax of the expression must satisfy the grammar for patterns), and (b) the pattern P must be motionless, as established by the rules in [Classifying Patterns].
This disqualifies expressions that use positional predicates: for example descendant::section/child::para[1] does not qualify because this would require information about a streamed node (specifically, about its preceding siblings) that is not retained during streaming.
The rule also disqualifies expressions that use constructs not permitted in a pattern, such as calls to stylesheet functions (even if the functions are declared as streamable).
Received on Wednesday, 7 December 2016 12:02:29 UTC