At 2005-02-20 11:19 -0800, Mukul Gandhi wrote:
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:
http://lists.xml.org/archives/xml-dev/200307/msg00880.html
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:output method="text"/>
<xsl:preserve-space elements="*"/>
<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:
T:\>type test2.xml
<?xml-stylesheet href="test2.xsl" type="text/xsl"?>
<address>
<address-line>Box 266</address-line>
<address-line><city>Kars</city> <province>Ontario</province></address-line>
<address-line><country>Canada</country>
<postcode>K0A-2E0</postcode></address-line>
</address>
T:\>type test2.xsl
<?xml version="1.0" encoding="iso-8859-1"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
<xsl:output method="text"/>
<xsl:preserve-space elements="*"/>
<xsl:template match="/">
<xsl:for-each select="/address/address-line">
<xsl:apply-templates/><xsl:text>
</xsl:text>
</xsl:for-each>
</xsl:template>
</xsl:stylesheet>
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.
.................... Ken
--
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman mailto:gkholman(_at_)CraneSoftwrights(_dot_)com
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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--