This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
It was noted in the NY F2F minutes: In xsl:with-param, we might take into account the sweep of the expression if the @as forces atomization. In fact this is equally true for other variable binding elements. I think we can add to the list of node-value contexts in section 19.3.1: * The expression in the select attribute, or the contained sequence constructor, of an xsl:variable, xsl:param, or xsl:with-param element, if the element has an "as" attribute whose value is a SequenceType that exclusively permits atomic values and/or functions * The contained sequence constructor of an xsl:variable, xsl:param, or xsl:with-param element, if the element has no "as" attribute Rationale: both these situations prevent the value of the variable being a node in a streamed document. In the list of node-value contexts we currently have: * the select attribute of one of the instructions xsl:analyze-string, xsl:attribute, xsl:comment, xsl:copy, xsl:copy-of, xsl:namespace, xsl:processing-instruction, xsl:value-of we should add xsl:message and xsl:assert to the list. We should also add the sequence constructors contained in all these instructions with the exception of analyze-string; in all these cases the supplied value will be either copied or atomized.
The sequence constructor of a literal result element falls into the same category: the result is always copied.
Changes applied, subject to WG review. A careful trawl of XSLT instructions revealed quite a few more cases where the result of an expression is always atomized or copied, for example the value attribute of xsl:number and the key attribute of xsl:map-entry, and these have been added to the list. For xsl:with-param on xsl:call-template, the @as attribute of the corresponding xsl:template/xsl:param is taken into account. This is consistent with the treatment of parameters to function calls.