[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: MSXML Whitespace handling

Subject: RE: MSXML Whitespace handling
From: Andrew Kimball <akimball@xxxxxxxxxxxxx>
Date: Tue, 1 Aug 2000 20:14:39 -0700
whitespace in xslt
Mike,

> Although the XML spec does make it clear that the parser has the option of
> discarding insignificant whitespace, the XSLT spec makes it sound like I
can
> expect whitespace characters in my physical document...

Where does the spec say "physical document"?  The spec uses the term "input
tree" -- I think deliberately, because it does not imply that the XSLT
processor constructed the tree.  I would love to hear James Clark's input on
this point, since it is the crux of this discussion.

> ...to be preserved if they're in xsl:text.

The XSLT rules only apply when there is space in the input tree.  In this
case, the DOM stripped this space when building the input tree, presumably
with the user's permission.

> ...However inaccurate that may be, it would seem to be
> preferable to preserve whitespace if you know that the DOM will be used as
> the basis of a stylesheet tree.

MS DOM does not have this information.  When the user loads the DOM, they do
not have to declare that it will be used as the basis of a stylesheet tree.
Why should they have to?  They may use the same DOM as the basis of
transforms, selections, and custom DOM API tree walks.  They may even
perform these operations concurrently if the DOM is free-threaded.  They may
have the same DOM running  on their server for days, peforming hundreds or
thousands of transforms over its data.

The point is that the user has control over initial whitespace handling.
XSLT has control only when the user begins a transform.

~Andy Kimball
MSXSL Dev


-----Original Message-----
From: Mike Brown [mailto:mike@xxxxxxxx]
Sent: Tuesday, August 01, 2000 4:53 PM
To: xsl-list@xxxxxxxxxxxxxxxx
Subject: Re: MSXML Whitespace handling


Andrew Kimball wrote:
> I think it was the right decision for the vast majority of users.

For users of the MS DOM, sure. For users of the MS DOM when it is being used
as the basis of the stylesheet tree in XSLT processing, I think that Mike
Kay's statement still stands:

>> I accept the argument that it is legitimate to allow the user to mangle
>> the tree before passing it to XSLT, but it seems wrong to mangle it by
>> default.

Your response is:
> Users who need to preserve whitespace can always set 
> preserveWhiteSpace=true when loading the DOM, or use
> xml:space="preserve" to tag significant whitespace.

The XSLT 1.0 Recommendation doesn't contain a warning that xsl:text elements
should be written with xml:space="preserve" in order to ensure whitespace is
handled as one would expect. My guess, as I detailed in an email yesterday,
is that the spec was written without taking this into consideration.

Although the XML spec does make it clear that the parser has the option of
discarding insignificant whitespace, the XSLT spec makes it sound like I can
expect whitespace characters in my physical document to be preserved if
they're in xsl:text. However inaccurate that may be, it would seem to be
preferable to preserve whitespace if you know that the DOM will be used as
the basis of a stylesheet tree.

-Mike B.


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.