- From: <bugzilla@jessica.w3.org>
- Date: Wed, 10 May 2017 11:02:49 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=30109 --- Comment #1 from Michael Kay <mike@saxonica.com> --- Looking at this more closely, I've come to the conclusion that it's not actually a problem. Although the statement that "when temporary output state is in effect, the request to disable output escaping is ignored" no longer applies to constructs such as <xsl:attribute name="x"> <xsl:value-of select="<" disable-output-escaping="yes"/> </xsl:attribute> the effect of the rules is that disable-output-escaping has no effect here anyway. The constructs that no longer set temporary output state, like xsl:attribute, generally invoke the rules of "Constructing Simple Content" (CSC). So the semantics here are: (a) xsl:value-of creates a text node, in which the DOE bit is set on every character. (b) the input sequence supplied to CSC comprises this singleton text node. (c) CSC causes the text node to be atomized (d) the resulting string is used as the string value of the attribute node. Since the rules for atomizing a text node say nothing about how the DOE bit might influence the process, we can safely conclude that the DOE bit has no effect, and that the disable-output-escaping attribute has therefore been effectively ignored. Proposal: after the paragraph stating: <quote> If output escaping is disabled for an xsl:value-of or xsl:text instruction evaluated when temporary output state is in effect, the request to disable output escaping is ignored. </quote> add a Note: <quote> Note: Furthermore, a request to disable output escaping has no effect when the newly constructed text node is used to form the value of an attribute, comment, or processing instruction. This is because the rules for constructing such nodes (defined in [5.7.2 Constructing Simple Content]), cause the text node to be atomized, and the process of atomizing a text node is not affected by the disable-escaping property. </quote> There is one case this does not cover. XSLT 2.0 set temporary output state during evaluation of xsl:message; XSLT 3.0 does not. So whereas 2.0 said that d-o-e while writing xsl:message was definitely ignored, 3.0 has no such statement; but since serialization of xsl:message results is entirely implementation-defined, I think we can live with that. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 10 May 2017 11:02:57 UTC