I am confessing that in Orcas we did a breaking change in the XslCompiledTransform.
Scenarios that load XslCompiledTransform from the XmlTextReader may handle whitespaces differently in the Orcas and in the Whidbey.
Preamble: .NET Framework 2.0 introduced new implementation of XmlReader to read XML from text stream. This class doesn’t have any public name and can be instanciated by call to XmlReader.Create() method. Let’s name it here “new reader” to distinct from XmlTextReader – the “old reader.”
“New reader” is faster and more W3C compliant, but fixing compliance bugs often result in breaking old behavior. For this reason Framework 2.0 was shipped with two xml readers “new” and “old”.
One thing that was fixed in “new” xml reader is whitespace handling. “Old” reader considered “   ” as a text node; “new” one reports it as whitespace.
XslCompiledTransform when it performs whitespace stripping need to distinguish whitespace nodes from text nodes. In Whidbey it relies on node type reported by xml reader. Some readers report it incorrectly. XmlNodeReader reports all whitespace nodes as text nodes and for this reason you can’t load stylesheet with element like this:
<xsl:include href=”foo.xsl”>
</xsl:include>
New line inside of element would be considered a text node and XslCompiledTransform would report a syntax error.
XLinqReader also decide not report whitespaces correctly and to avoid compatibility issues with XslCompiledTransform last one doesn’t trust XmlReader on whitespaces anymore and detects whitespaces itself.
The Problem: Some users used the fact that “old” xml reader reports “   ” as text and used it as a way to control whitespace stripping process during XSLT load. When they want prevent WS from stripping they represented it as entity. (Once again, this did work only when XslCompiledTransform.Load() called with “old” xml reader.)
This was not W3C compliant behavior and the trick would not work in Orcas version of Framework.
Workaround: The best solution is fixing the stylesheet by replacing “   ” to <xsl:text>   </text> or just <xsl:text> </text>.
If you have any stylesheets which were hurt by this breaking change and can’t process them by hands you can always write program that reads each of them into text buffer, creates both “old” and “new” xml readers over this buffer and compare results of these readers. Text nodes that reported by “old” xml reader as WS this program would wrap with <xsl:text> element.
