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.2 we say: "For constructs other than expressions, the static type for the purpose of streamability analysis is taken as item()." I don't think this is correct, some constructs, like xsl:function, are analyzed based on the as-type of the xsl:param elements, they are not always item().
I'd be grateful for specific examples. xsl:function is a declaration, it is not a "construct" as this term is used in the streamability analysis. A function call is analysed based on the xsl:function/@as attribute, but the function call is an expression and that's covered by the existing rules.
You are right that xsl:function is not an instruction, and thus not a construct for streamability analysis, I didn't consider that. The call to a function is, however, a construct, but that is already covered. Another appearance where we have a construct, but not the static type of item() is xsl:variable: <xsl:variable name="foo" as="xs:string"> <xsl:value-of select="bar" /> </xsl:variable> This is allowed in streaming, is a construct, but has type other than item(). The streamability works here, because the sequence constructor is grounded. But even if the sequence constructor contained xsl:sequence instead of xsl:value-of, it would still be grounded, however, that is not covered in the streamability of xsl:variable currently, I believe (the operand role is the seqtor, the usage is navigation, though we could use TDU here, albeit a bit off-topic for this bug-report). Perhaps I misunderstand the mentioned sentence. Apparently, TDU is only applied to operand roles, not to whole constructs, in which case the sentence itself is true, albeit for me a tad confusing.
We discussed this at the face to face meeting in Prague. In 19.8.4.38, we say that the usage of the @select is navigation, but in fact we could usefully say that in the presence of an @as attribute, the declaration has type-determined usage. (As suggested in comment 2.)
The change agreed for this bug has in fact already been made under the resolution of bug #24109. No further action needed.