I am sorry for another post on this subject! I am
sorry if it annoys anyone.. I feel my duty to post
this, as the views I expressed might have raised some
doubts..
I just read an interesting article on Microsoft site
about MSXML.. I have marked some phrases with * ,
which caught my attention more..
History of MSXML (quoted from Microsoft site)
---------------------------------------------
When MSXML 2.0 first shipped, it introduced support
for one of the first W3C XSL working drafts, which
included a path-based language *known at the time as
XSL Patterns*. It also included push-model interfaces
available through the IXMLParser and IXMLNodeFactory
interfaces.
As time passed, the underlying specifications
solidified. The original XSL working draft was
factored into several independent specifications,
including XPath 1.0 and XSLT 1.0. And during the same
time frame, SAX evolved into the de facto streaming
(push-model) API for XML documents. The *XML standards
landscape* had changed dramatically and *MSXML had to
follow suit*.
The MSXML team shipped version 3.0, which *included
support for these now stationary specifications*. But
*instead of immediately deprecating the preceding
versions, they decided to leave them in and make them
the default implementation in order to foster backward
compatibility*.
Although the MSXML 3.0 components are installed in
side-by-side mode by default, you can optionally run
xmlinst.exe to place them in replace mode. *Replace
mode forces older applications to load the newer
components*(of MSXML 3.0). This decision ultimately
backfired because it confused developers and *the
replace mode made applications harder to maintain and
somewhat fragile*. The confusion was evident on the
MSXML-related mailing lists and newsgroups where a
large percentage of the most common, recurring
questions were directly related to the differing
implementations.
A similar issue existed with the XSL/XSLT
implementations, only *it was subtler since the actual
implementation was determined by the namespace in the
transformation document*.
You might argue that since all of this was clearly
documented, developers should have known better. But
in reality, no matter how good the documentation,
*having too many options and not-so-obvious defaults
always leads to confusion*.
Problems like this one coupled with *the resulting
confusion forced the MSXML team to simplify the
library by completely removing the legacy code along
with replace mode* starting with the July 2001
Technology Preview release.
*But removing replace mode also means that you can no
longer control which version of the XSLT engine is
used by Microsoft Internet Explorer to process the
<?xsl-stylesheet?> processing instruction that is
often used to render XML documents*.
*Internet Explorer 5.0 will now be restricted to MSXML
2.0 (or MSXML 3.0 in replace mode) until they deploy a
new version written against the latest MSXML release*.
Of course, Web developers can still use the latest and
greatest XSLT engine, or any other new MSXML
components for that matter, by simply referencing the
appropriate version-dependent PROGIDs *in script*.
Overall, these changes are positive for the future of
MSXML.
This sentence caught my attention most in the above
artile(in light of this thread)..
"A similar issue existed with the XSL/XSLT
implementations, only it was subtler since the actual
implementation was determIined by the namespace in the
transformation document."
I won't offer my further comments(as much has been
discussed already).. I'll let readers to think(and
experts to comment)..
Regards,
Mukul
--- David Carlisle <davidc(_at_)nag(_dot_)co(_dot_)uk> wrote:
David, if you agree with my understanding, we
may
close this thread.
I think we should close it anyway;-)
If MSXML4 is able to run in IE by default, we'll
get
desired behaviour.. This we can wish, will
happen
in
future versions of IE.
the behaviour you describe was exactly the same
before msxml4 came out,
if you use msxml3 outside IE you can get the right
behaviour.
It is all about whether IE allows you to set the
whitespace property, not
about whether it uses msxml3 or 4 (but I said this
before)
Of course to simplify things a bit (and in a vain
attempt to close this
thread earlier) I lied to you about msxml's white
space behaviour,
it doesn't _completely_ remove all trace of the
white space nodes that
it drops: it remembers where they were (although
not, I think, exctly what
space was there) and sometimes, if it feels like
it,
it tries to
re-insert the nodes.
So you get the following beghaviour which clearly
incontrovertibly
does not comply to the XSLT spec. There is no
input
tree that can
validly produce the output that you get below,
from
a slightly modified
version of your test files.
If you save the folling xml and xsl as ws.xml and
ws.xsl respectively
then
in firefox you get a count of 5 and the two ways
of
doing an
identity transform produce the same result.
the white space (including a newline) is rendered
in
the pre element so
you get bold and italic on separate lines.
In IE you get a count of 2 and the second identity
transform (using
apply-templates) shows spaces have been dropped as
we have discussed,
but if you use copy-of as in the first identity
transform the white
space nodes come back by magic, but not as a
newline, just as a space
so you get bold and italic on the same line
separated by a space.
Basically if you construct the node list "by hand"
using apply-templates
then the result tree doesn't have any of the magic
markers but if you
copy a whole node then white space markers in its
descendants get copied
and when these are serialised they do (in some
circumstances) generate
white space in the result tree.
David
<?xml-stylesheet type="text/xsl" href="ws.xsl"?>
<pre>
<b>bold</b>
<i>italic</i>
</pre>
<?xml version="1.0"?>
<xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
version="1.0">
<xsl:template match="/">
<html>
<head/>
<body>
<p>
count: <xsl:value-of
select="count(/pre/child::node())"/>
</p>
<p>identity 1:</p>
<xsl:copy-of select="."/>
<p>identity 2:</p>
<xsl:apply-templates/>
</body>
</html>
</xsl:template>
<xsl:template match="*">
<xsl:copy>
<xsl:apply-templates/>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>
________________________________________________________________________
This e-mail has been scanned for all viruses by
Star. The
service is powered by MessageLabs. For more
information on a proactive
anti-virus service working around the clock,
around
the globe, visit:
http://www.star.net.uk
__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail
--~------------------------------------------------------------------
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>
--~--