W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2017

[Bug 30109] [xslt30] Sticky disable-output-escaping revisited

From: <bugzilla@jessica.w3.org>
Date: Wed, 10 May 2017 11:02:49 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-30109-523-siDqtJtz1B@http.www.w3.org/Bugs/Public/>

--- 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="&lt;" disable-output-escaping="yes"/>

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

(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:

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.

add a Note:

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.

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:58:04 UTC