This past weekend (05 Jan 2008) our production servers were updated with a large set of MS Windows 2003 updates by our systems team. I suspect that one of those updates included a .NET 2.0 update. Monday morning I started getting support calls about an application breaking. After much searching and debugging, I was able to track it down to malformed HTML hyperlinks which contained bogus characters.

I have a web application in ASP.NET 2.0 that uses the XslCompiledTransform class. I'm transforming XML (let's call this "source content") to XML (this one can be "content tree") and then later using the result as a source for building a treeview control for presentation. The treeview contains hyperlinks to display the section of content.

Here is a sample of the XSL file in question:

[snip]
    <xsl:variable name="ThisXPath">
        /baseVehicle[@aaia_id=<xsl:value-of select="/baseVehicle/@aaia_id"/>]
        /level0[@source_id=<xsl:value-of select="@source_id"/>]
    </xsl:variable>
    <xsl:attribute name="NodeData">
        <xsl:value-of select="$ThisXPath"/>
    </xsl:attribute>
    <xsl:attribute name="id">A<xsl:value-of select="@source_id"/></xsl:attribute>
    <xsl:attribute name="Type">level1</xsl:attribute>
    <xsl:attribute name="NavigateUrl">
        javascript:parent.TreeClick('<xsl:value-of select="$ThisXPath"/>')
    </xsl:attribute>
[/snip]

The value created for the "ThisXPath" variable is (as the name implies) used as an XML XPath later on. The value is embedded into an HTML hyperlink to be passed off to another page which then uses the XPath value to get a subset of nodes from the master content document (source content).

At first glance it would make sense that the structure of that variable value as well as the last attribute (NavigateUrl) is incorrect for use as an XPath. Despite this, up until this weekend it worked fine. However, Monday I noticed that the Hyperlinks now contained extra encoded characters. When I stepped through the code I found the value for the attribute "NavigateUrl" coming from the transformed xml (content tree) contained leading characters like this "\n\t\t". This correlates with the literal characters in the initial transformation XSL file. My resulting Hyperlink url then showed up like this in the browser:

    "%0a%09%09javascript:top.TreeClick('%0a%09%09/baseVehicle..."

This being the combined result of whitespace in the xsl:variable and the "NavigateUrl" attribute.

The point of this all being: up until this weekend, all was well, the whitespace in the XSL file seemed to be ignored. Then things changed.

I was able to fix it simply by removing the unnecessary whitespace from the XSLT.

I've been googling for a while now but have yet to come up with a definitive answer. Reading about the standard behavior I'm still confused about whether or not and in what cases whitespace should be preserved. It seems that until a recent update, the .NET XSL class did not preserve the whitespace in the source XSL.

Has anyone heard of this problem or know of such a bug (and apparent subsequent fix) with the .NET 2.0 transform classes?

-Peter

__________________
-Peter
compiledthoughts.com
twitter/peterlanoie

It's a well-known problem with the Microsoft parsers that they strip text nodes that consist entirely of whitespace without a by-your-leave. However, I've never heard of them stripping whitespace characters that are part of a text node that also contains printable characters, and that would certainly be a serious bug. You should get rid of them using translate().

Michael Kay
http://www.saxonica.com/
Author, XSLT Programmer's Reference and XPath 2.0 Programmer's Reference