Looking for a white-space work-around (Was: Resu
I am requesting more clarity for the rules of stripping "white space only text nodes" ... And the ambiguity is still there!
Please review my post I cited earlier where I detail there is no ambiguity:
I included a link to this post in my first response to avoid having to rehash the discussion from July 2003 all over again. The reader was supposed to follow that link and understand the situation. My objective was only to try and help the original poster understand a confusing situation should he have been using a processor that was not conformant in the area of white-space handling.
Unfortunately, still today my customers are getting caught short by this problem.
What is *really* a pain is I believe there is no stylesheet work-around if I'm using MSXSL in Internet Explorer through stylesheet association where I have no access to making any API calls.
Consider the following example:
T:\>type test.xml <?xml-stylesheet href="test.xsl" type="text/xsl"?> <pre> <b>bold</b> <i>italic</i> </pre>
T:\>type test.xsl <?xml version="1.0" encoding="iso-8859-1"?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:template match="/"> <xsl:value-of select="count(/pre/child::node())"/> </xsl:template>
</xsl:stylesheet> T:\>saxon test.xml test.xsl 5 T:\>msxsl test.xml test.xsl con 2 T:\>
My "msxsl.bat" is just an invocation of the DLL. You get the same "2" result if you put the two files above into a directory and open the XML file from IE.
Note that I have included a *redundant* <xsl:preserve-space/> instruction that shouldn't be necessary but is what I tried to use to allow my customers' data to be displayed through Internet Explorer using stylesheet association.
This would be a painless addition to a stylesheet that I could live with because it has no side-effects to conformant processors ... after all, the declaration is redundant. But, no, it doesn't help me (or my customers) at all.
And the problems aren't limited to the source file either.
Consider the following where I have my address marked up with rich markup in mixed content so as to identify the components. I would typically have template rules for the components so that during presentation I could do things like emphasize the country in a formatted address. But in the example below I've not included these template rules and I just engage the default template rules with a simple newline sequence at the end of each line captured in an <xsl:text> instruction:
<?xml-stylesheet href="test2.xsl" type="text/xsl"?>
<?xml version="1.0" encoding="iso-8859-1"?>
<xsl:template match="/"> <xsl:for-each select="/address/address-line"> <xsl:apply-templates/><xsl:text> </xsl:text> </xsl:for-each> </xsl:template>
T:\>saxon test2.xml test2.xsl Box 266 Kars Ontario Canada K0A-2E0
T:\>msxsl test2.xml test2.xsl con Box 266 KarsOntario CanadaK0A-2E0 T:\>
Notice how both the spaces between city and province, and between country and postcode are lost due to not conforming on the source node tree, and the newline sequence from the stylesheet is being changed to a space due to the DLL not conforming to the W3C specification on the stylesheet tree.
At least I can work around the stylesheet newline issue by adding xml:space="preserve" to the <xsl:text> instruction ... but I shouldn't have to do so to keep the newline. And if the DLL supported <xsl:preserve-space/> in a conformant fashion, then I would have enough work-arounds for the problems noted above.
Is anyone aware of changes to a stylesheet that would trigger the Microsoft DLL to interpret source-tree white-space-only text nodes in a conformant fashion in the IE browser environment where I have no access to DLL calls, and with those changes have no effect on conformant XSLT processors?
Thanks for any help anyone can be. I have had a hard time for years now trying to explain these shortcomings to my customers and if there was an innocuous work-around then they wouldn't have to know.
-- World-wide on-site corporate, govt. & user group XML/XSL training. G. Ken Holman mailto:gkholman@xxxxxxxxxxxxxxxxxxxx Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/ Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995) Male Breast Cancer Awareness http://www.CraneSoftwrights.com/s/bc Legal business disclaimers: http://www.CraneSoftwrights.com/legal
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format