At 01:42 PM 07/07/2001 +0300, Thamir Abdullatif wrote:
>...does MSXML3 support fully the element is XSLT 1.0 and all
>functions, axis names in XPATH?
Whatever else one might say about MS's technological and business
practices, MSXML3(+) is a terrific product.
(Of course, as someone else pointed out, it's not platform-neutral. Its
processing may be included in some form in the Mac version of MSIE (I don't
know anything about Macs), but what people usually refer to as MSXML is
otherwise always a Windows .dll by that name.)
Now, they *did* make some (IMO) annoying decisions when they built it.
First, there's the default whitespace handling. MSXML is a combination XML
parser and XSLT processor. Thinking of its XML 1.0-compliant parser, you
might imagine MSXML's default whitespace behavior would be to preserve it.
Not so. The *parser* does that, all right, but then -- again, by default --
before it hands off the tree to the XSLT processor, it *normalizes*
whitespace. You can control this behavior using a flag called (I think --
working off the top of my head here) preseveWhitespace (value true or
false). But that flag must be set before the XSLT processor gets the
document tree from the parser, i.e. in script or code.
Second, and this is in some ways a biggie, per their commmon practice they
made MSXML backwards-compatible with an early Working Draft of the XSLT
spec. So you can code up your XSLT to conform to EITHER the
3-years-out-of-date version, OR the up-to-date XSLT 1.0 Recommendation.
Unfortunately, it took their documentation -- and books covering XSLT -- a
long time to catch up to XSLT 1.0. As a result, people still post questions
about stylesheets they've created which are failing for some reason or
another... coded per the 1998 WD.
Also, there's this: When you use MSIE5.5+ to view an XML document which has
no xml-stylesheet PI, by default it displays the document as an
expandable/collapsible tree of elements, attributes, and what-not. This is
a perfectly reasonable generic way of viewing an XML document. But the way
that the browser accomplishes this is with a built-in "XSLT" stylesheet,
which transforms the XML on the fly to a kind of "dynamic XHTML," and that
result tree is what you're actually seeing in the browser. I put "XSLT" in
quotes there because the stylesheet in question conforms to the earlier WD,
*not* to the current 1.0 Recommendation. The built-in stylesheet also uses
some MS tricks to gain access to, e.g., the XML declaration and DOCTYPE
Those issues aside, the answer to your question is still "Yes." The
annoyances don't have anything to do with its support for XSLT 1.0.
The first 2/3 of my book "Just XSL" (out sometime in the next 6 weeks or
so) covers XSLT, and I was able easily to use MSXML3-in-IE to demonstrate
just about everything. I could have used it to demonstrate *everything* if
I'd wanted to write up VB or ASP code to do so, but I didn't want to have
to teach my readers that, too. :) For the few cases in which I couldn't
easily demo a principle with MSXML, I used Michael Kay's Saxon -- which is
not only fully compliant but also cross-platform. (And it's even rather
forward-looking; Kay incorporates experimental implementations of features
to be added to XSLT in version 2 of the spec.)
If you have practical or philosophical reasons not to use MSXML, you can do
a lot worse than Saxon as your XSLT processor. Other good ones (although I
haven't used them all) are Apache Xalan (based on IBM's LotusXML), James
Clark's XT (very fast, but doesn't support keys and, I think, no longer
being developed), Unicorn UXT, and (for Python developers) 4XSLT.
Information on all of them is available at the www.xmlsoftware.com site,
Robin Cover's staggeringly complete XML Cover Pages, at
John E. Simpson | "I plugged my phone in where the blender
http://www.flixml.org | used to be. Then I called someone. They went
XML Q&A: www.xml.com | 'Aaaaahhhh...'" (Steven Wright)