Thanks for your answer.
The transform is indeed written to an XmlWriter. I have attached the current code for the function which I use for XML-XSL transformations. The XmlWriterSettings are experimental.
Main Topics
Browse All TopicsI have an XSL-file, which I use to transform XML.
When I load the XSL into an XmlDocument, it gets spaces introduced, and that matters especially on
<textarea><xsl:value-of select="." /></textarea>, because it introduces spaces in the output where there should be none.
By the way: I do use XslCompiledTransform for the XSL only in a later phase, because some things need to be edited on the fly. And anyway it must be possible to NOT introduce whitespace in XmlDocument.
".PreserveWhitespace = False" is not helpful. The result still indents every nested node with a linefeed plus 2 spaces. Even if the source in the file has none of those.
EDIT:
It is sort of funny that ".PreserveWhitespace = True" will no longer introduce linefeeds and spaces when they are not in the sourcefile. On the other hand it introduces problems when there *is* white space: white space is then parsed as nodes of type "System.Xml.XmlWhitespace"
sigh
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.

Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
A statement like this in the XSLT:
<td valign="top"><xsl:value-of select="caption" /></td>
will work the same if it were looking like this:
<td valign="top">
<xsl:value-of select="caption" />
</td>
because XSLT removes all non-relevant spaces, they never become part of the result tree. The only spaces that remain are inside <xsl:text> elements, which must become part of the result tree.
Any spaces introduced are introduced by the serializer of the XSLT processor or the serializer of yourself (which has some pretty interesting settings). Try to do the .Transform() directly to a file and see if that changes the behavior (and inspect that file in the source).
-- Abel --
Thanks for your input so far.
The problem is that I do not know where exactly the spaces are being introduced. There are quite some possibilities. Here is what I found
* My XML (XmlDocument) is generated on the fly, nodes are added with CreateElement() and AppendChild. When the XML has been created, I can do a XML.Save(Response.OutputSt
Depending on the value of the PreserveWhitespace property of the XML, the result has white spaces.
.PreserveWhitespace = True
-> no whitespace introduced
.PreserveWhitespace = False
-> whitespace is introduced: each node is on a new line and has 2 leading spaces for each nesting level of the node
So apparently here is where the trouble starts: .PreserveWhitespace influences two things:
1. ignore whitespace or not
2. introduce its own whitespace or not
I have attached some simple code which illustrates the second behavior, although the difference is only visible in the View Source of the browser. The first effect (ignoring whitespace) is fine and even useful. The second effect causes my trouble with the XSL.
It is possible that "oXML.Save(Response.Output
> It is possible that "oXML.Save(Response.Output
yes, that's exactly what it does.
I actually meant you to create an XSLT transform directly to disk. It may seem strange, but the above introduces many places for introduction of white space. Here's a crash course on whitespace and XSLT:
Whitespace in source document is considered text and is preserved by default
Whitespace in XSLT document is ignored everywhere but in the xsl:text elements
Specific whitespace (
 etc) are always preserved, also in XSLT doc
Whitespace is introduced on serialization
Serializing to HTML treats certain objects different when indent=true, to prevent whitespace added to tags like <pre>
To find out where the culprit is do the following:
Create an XSLT document (with any amount of whitespace)
Create a simple input XML document
Transform them the simplest way possible (see below)
Show me the input/output/xslt and code you used
then I can explain you what whitespace was added where and why. Later we'll introduce the rest of the necessary logic again.
-- Abel --
> It is possible that "oXML.Save(Response.Output
yes, that's exactly what it does.
I actually meant you to create an XSLT transform directly to disk. It may seem strange, but the above introduces many places for introduction of white space. Here's a crash course on whitespace and XSLT:
Looks Dutch ;-)
There's specific whitespace in the source document, which is transformed into attributes. Whitespace in attributes is always significant (not in XSLT for obvious reasons). This is an XML rule, not an XSLT rule.
Do I understand you correctly that all source whitespace should be collapsed? I.e., that the resulting whitespace should be stripped (all multiple whitespace into a single one)?
Yep, Dutch.
It started with a HTML-textarea which had whitespace coming from nowhere. The ultimate purpose is of course understand what is going on. Which factors influence the whitespace and how.
Where is the whitespace introduced, and how can it be prevented. And then I am talking about the formatting whitespace: each node gets a linefeed + two spaces for each nesting level.
The test from above shows that it is not XslCompiledTransform that does it.
XmlDocument() has a property ".PreserveWhitespace" which seems to do 2 different things: first eliminate whitespace, then introduce its own whitespace (with value "False").
Or is the introduction of that own whitespace a result of something else?
I think we're on the same page there: the whole test was to find out where the problem lies.
Once you load it into XmlDocument, the original stream is transformed into a DOM document. When you serialize the again, you can introduce new whitespace. Use for serialization the XmlWriter and use the XmlWriterSettings object for setting the indent bits. The preserve whitespace is not something you should worry about.
When you serialize a DOM document, every character is interpreted according to the rules you set out in the XmlWriter. If you do this incorrectly, you can all of a sudden change the charset of the XML or introduce whitespace (as you noticed).
Most libraries have indentation off by default. Microsoft has it on by default.
If possible, do the XslTransform directly to disk or stream, to prevent this trouble. Every step you introduce can introduce whitespace because of indentation.
In addition, HTML is treated specially by the XSLT transformer (this is mandated by the standard). However, as soon as you load the HTML as XML in a DOM, this extra information is lost and a textarea or pre tag is treated the same as any other.
-- Abel --
Business Accounts
Answer for Membership
by: abelPosted on 2009-08-14 at 06:04:53ID: 25097499
Is it possible that before you apply the XSLT to the XslCompiledTransform, you serialize to either a string, to memory or to disk (or event: implicitly?). Are you positive that the spaces are introduced in the XSLT and if so, how did you notice (because you can only see that once you serialize the XSLT)?
The reason I'm asking is because the XmlWriter you use might indent your code. If you want that to stop, you should set the options on the XmlWriter to not to indent that output.
The same applies to the XML after the XslCompiledTransform: if you output the result not to a file but to an XmlWriter for instance, the settings of the XmlWriter will overrule the settings inside the XSLT (in which you can have <xsl:output indent="false" />).
Even more, if you have <textarea> <xsl:value-of select="." /> </textarea> then the XSLT compiler should treat that as insignificant whitespace. Meaing: it must be ignored (stripped) before applying the stylesheet. The specification says about that: "For stylesheets, the set of whitespace-preserving element names consists of just xsl:text."
That said, I'm under the impression that though the problem seems to lie in the XmlDocument parsing of your XSLT, it may actually lie somewhere else.
If this doesn't help you enough to pinpoint the problem, is it possible for you to mock up a simple example with xslt + input + result and what the expected (corrected) result should be, including a few lines of C# you use for the serialization?
-- Abel --