Yeah Mukul, I know, but this is old news... I still see myself using WD-XSL,
for what is what it was awesome. The big mistake MS made was not to follow
the standard, I guess because they want to be the standard themselves (?) -
it was a wrong decision.
Now they know better - you can see that with decisions around bringing
XQuery 1.0 or not in Whidbey and Yukon - leaving only a subset to come in
the latter. That is after all a better decision, taking into account
possible changes until the spec becomes W3C Recommendation.
However, I still think MS's decision to exclude XSLT 2.0 from the big
picture is a wrong decision. With Saxon.NET
(https://sourceforge.net/projects/saxondotnet/) we're going to add it
anyway, so no worries there - and there are more projects, like XQP
(http://sourceforge.net/projects/xqp).
I now realize this thread is way OT... which leads me to the original Q...
has this been answered? I don't even see Sebastien comment, but it's the
longest thread I've seen until now and with my 2 cents it's going to be even
longer!! Anyone else? :-)
Cheers,
<prs/>
http://www.pietsieg.com
-----Original Message-----
From: Mukul Gandhi [mailto:mukul_gandhi(_at_)yahoo(_dot_)com]
Sent: Thursday, February 24, 2005 7:30 AM
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: Re: [xsl] Result still indented despite indent="no"
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>
--~--
--~------------------------------------------------------------------
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>
--~--