This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
One would expect that when the context node is a text node (or comment or PI) that there is some motionless way to get the string value (or typed value) of the node. Naively, for example, one might expect that the pattern match="text()[. = 'intro']" is motionless. But it isn't, because our analysis has no way of taking into account the fact that "." in this context refers to a text node. This requires type analysis. To make matters worse, there is no alternative way of getting the value of the node in a way that is analysed as motionless. This also affects accumulators, because the new-value expressions in an accumulator must be motionless, so they will often need to fire when text nodes are encountered. There's no other way of accessing the content of a text node as input to an accumulator. I can't see any way forward on this other than introducing some limited type inferencing.
I think the refinement of the rules could take the form sketched out below: * A construct that is analysed using the normal rules as consuming becomes motionless if the inferred type of the context item is a node that cannot have children, that is, a text, comment, processing-instruction, attribute, or namespace node. * The inferred type of the context item for a construct C is determined as follows. Certain constructs are context-changing; such constructs have a context-setting subconstruct P which determines the context item used by other subconstructs. Specifically: - path expressions P/Q - simple mapping expressions P!Q - filter expressions and steps P[Q] - xsl:for-each select="P" body <Q> - xsl:template match="P" body <Q> - ... For any construct C if there is an enclosing context-changing construct CCC such that C is not in the context-setting part of CCC then let S be the context-setting part of the innermost such enclosing construct; if S is one of the following: - a stepexpr using a kindtest selecting kind K as its nodetest - a relativePathExpr with such a stepExpr as its last step - a pattern in the form of such a StepExpr - ... then the context item type for C is K.
We (MK + Abel) examined this problem, and reluctantly, we see no alternative to the proposed way forward.
The type inference logic to make atomizing a text node a motionless operation is now in the current draft spec.