This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
(Reported by John Lumley) The following template is deemed non-streamable under current rules: <xsl:template match="your:extra" mode="s" xmlns:your="http://your.com/ns"> <extra> <xsl:variable name="n" as="xs:integer" select="."/> <xsl:value-of select="$n gt 20"/> </extra> </xsl:template> The analysis fails to take into account that the as="xs:integer" ensures the context item is atomized, and the usage should therefore be absorption. The concept of "type-determined usage" should come into this somehow.
More specifically: For the select attribute, the operand usage is type-determined if there is an "as" attribute, or navigation otherwise. For the contained sequence constructor, the operand usage is type-determined if there is an "as" attribute, or absorption otherwise.
The WG accepted the proposed change.
I am reopening this, because it seems the change introduced a new bug. Under 19.8.4.39, under the rules, list item 2.b., the usage of the seqtor operand has changed from navigation (previous draft) to absorption (current internal draft). This would allow the following to be streamable (sequence has usage transmission, seqtor usage absorption): <xsl:variable name="x"> <xsl:sequence select="foo"> </xsl:variable> but it isn't streamable, because the variable would hold a reference to a streamed node. Unless I misunderstand the change, I think the proper usage here is navigation, and not absorption.
I think it was correct as written. In your example <xsl:variable name="x"> <xsl:sequence select="foo"> </xsl:variable> the value of the variable $x is a document node containing a copy of foo, it's not a reference to the original foo node.
Indeed, it appears I got confused with the same rule for xsl:template, actually, I often make this mistake with xsl:variable. In which case, the previous WD was incorrect (having usage navigation) and the new draft fixed that. Thanks for the explanation. I think the bug can be closed again ;).
Closed again with no action, as suggested in comment #5.