[Bug 27051] [XSLT30] Resolution to bug 25185 introduced a bug in streaming rules of xsl:apply-templates

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27051

--- Comment #4 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
> I'm a little surprised to hear that the spec at one time allowed this.

For reference, it is here:
http://www.w3.org/TR/2013/WD-xslt-30-20131212/#dt-general-streamability-rules.
The last step applies the general streamability rules with absorption for
@select, and in the GSR we say that absorption with childless node kinds turns
absorption into inspection.

The rule for changing absorption into inspection applied to all of striding,
climbing and crawling postures (though text() or processing-instruction()
clearly can never be climbing).

This rule worked find in practice, because namespace and attribute axes have
always been motionless and you cannot select children from them.

> What about other places where we require (and assume) striding expressions,
> such as for-each and for-each-group and iterate? Is it safe to use 
> attribute::* in all these contexts, on the same basis?

This worked because of the GSR. Selecting a climbing axis with attribute nodes
on a for-each would result in a climbing context posture for the body of the
for-each, but in any absorption usage, the GSR kicks in and allows this because
the nodes are childless (GSR rule 1.b.iii).

So yes, while perhaps not ideal in terminology, it worked well. 

This bug report was deliberately specifically about xsl:apply-templates,
because the changes in the spec did not break existing rules for
xsl:for-each(-group), afaict, only for xsl:apply-templates.

> but it still doesn't feel right to make this switch from climbing to 
> striding as we enter the called template.
> I'm wondering if even selecting attributes from a climbing posture 
> can be made striding?

I believe that in XPath they are considered downward axes, and in light of
that, it has always been kind of odd to consider the attribute and namespace
axes climbing, but we had good reasons for it (it worked well with other
existing climbing axes like ancestor).

If we turn them into striding and motionless I think it simplifies many
situations, but also becomes a cameleon: it will be the only axis that can
change climbing into striding (but we have something similar to crawling with
text nodes, which changes crawling into striding).

Recognizing this situation and allowing more axis paths to be able to return
striding postures results in more expressions to be streamable without adding
complexity. I think that is a good thing.

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

Received on Sunday, 26 October 2014 14:57:48 UTC