W3C home > Mailing lists > Public > public-qt-comments@w3.org > September 2005

[Bug 1309] white space in the DM

From: <bugzilla@wiggum.w3.org>
Date: Wed, 28 Sep 2005 15:00:14 +0000
To: public-qt-comments@w3.org
Cc:
Message-Id: <E1EKdPq-0007Pa-7v@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1309





------- Additional Comments From Norman.Walsh@Sun.COM  2005-09-28 15:00 -------
The XSL WG also agreed to add the following non-normative text to the XSLT
specification:

It occurred to me during the discussion today that we ought in section 4.4
(which discusses xsl:strip-space) to mention the statement in the data model
that whitespace text nodes in element-only content are stripped before
xsl:strip-space/preserve-space comes into play. The place for this seems to
be in the existing note at the end of the section which currently reads:

Note:
A source document is supplied as input to the XSLT processor in the form of
a tree conforming to the data model described in [Data Model]. Nothing in
this specification states that this tree must be built by parsing an XML
document; nor does it state that the application that constructs the tree is
required to treat whitespace in any particular way. The provisions in this
section relate only to whitespace text nodes that are present in the tree
supplied as input to the processor. In particular, the processor cannot
preserve whitespace text nodes unless they were actually present in the
supplied tree.

I propose to change this to:

Note:
In [Data Model], processes are described for constructing a tree (an
instance of the data model) from an Infoset or from a PSVI. Those processes
deal with whitespace according to their own rules, and the provisions in
this section apply to the resulting tree. In practice this means that
elements that are defined in a DTD or a Schema to contain element-only
content will have whitespace text nodes stripped, regardless of the
xsl:strip-space and xsl:preserve-space declarations in the stylesheet.

However, source trees are not necessarily constructed using those processes;
indeed, they are not necessarily constructed by parsing XML documents.
Nothing in the XSLT specification constrains how the source tree is
constructed, or what happens to whitespace during its construction. The
provisions in this section relate only to whitespace text nodes that are
present in the tree supplied as input to the XSLT processor. The XSLT
processor cannot preserve whitespace text nodes unless they were actually
present in the supplied tree.


I think we should also say something in the compatibility appendix. I'd
suggest a new section J.1.2 before the existing J.1.2:

J.1.2 Tree Construction: whitespace stripping

In both 1.0 and in 2.0, the XSLT specification places no constraints on the
way in which source trees are constructed. For XSLT 2.0, however, the [Data
Model] specification describes explicit processes for constructing a tree
from an Infoset or a PSVI, while also permitting other processes to be used.
The process described in [Data Model] has the effect of stripping whitespace
text nodes from elements declared to have element-only content. Although the
XSLT 1.0 specification did not preclude such behavior, it differs from the
way that most existing XSLT 1.0 implementations work. It is RECOMMENDED that
an XSLT 2.0 implementation wishing to provide maximum interoperability and
backwards compatibility should offer the user the option either to construct
source trees using the processes described in [Data Model], or alternatively
to retain or remove whitespace according to the common practice of previous
XSLT 1.0 implementations.

To write transformations that give the same result regardless of the
whitespace stripping applied during tree construction, stylesheet authors
can:

* use the xsl:strip-space declaration to remove whitespace text nodes from
elements having element-only content (this has no effect if the whitespace
has already been stripped)

* use instructions such as <xsl:apply-templates select="*"/> that cause only
the element children of the context node to be processed, and not its text
nodes. 



I also spotted while reading section 4.4 that the following Note:

Note:
This implies that if an xml:space attribute is specified on a literal result
element, it will be included in the result.

is misplaced in section 4.4, since literal result elements do not occur in
source documents. I suggest we add it to the note at the end of 4.2,
rephrasing it to fit:

Note:
If an xml:space attribute is specified on a literal result element, it will
be copied to the result tree in the same way as any other attribute.
Received on Wednesday, 28 September 2005 15:00:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:08 UTC