[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Saxon and MSXML3 differences

Subject: RE: Saxon and MSXML3 differences
From: Andrew Kimball <akimball@xxxxxxxxxxxxx>
Date: Thu, 26 Oct 2000 12:02:41 -0700
msxml3 xpath
Jeni's analysis is correct.  This is a conformance problem in MSXML3.  The
MSXML XPath implementation works on top of the DOM, and the DOM data model
does not group text nodes (the discrepancies between the DOM and XPath data
models have caused no end of grief).  We were unable to come up with a
satisfactory 3.0 solution which mantains separate text nodes for DOM while
still collapsing nodes for XPath (or at least making it appear that way to
the XPath engine).  We will fix this in the future by reworking our current
architecture to utilize views and/or enabling XSLT to build its own cache
rather than working over the DOM (as most other engines do).  However, this
was just not feasible for the 3.0 release.  Your suggestion to use "." is
the best workaround for this problem.

~Andy Kimball
MSXSL Dev

-----Original Message-----
From: Jeni Tennison [mailto:mail@xxxxxxxxxxxxxxxx]
Sent: Thursday, October 26, 2000 9:21 AM
To: Lee Goddard
Cc: xsl-list@xxxxxxxxxxxxxxxx
Subject: Re: Saxon and MSXML3 differences


Lee,

>I've encountered unexpected output with both
>Instant Saxon and MSXML3.  Do you think it is
>the &trade; entity, defined in my DTD?

I don't know what version of Saxon you're using (it seems to work fine in
5.5.1), nor what you're viewing your output in (viewing output that
includes funny entities is always a little problematic because you need to
have a viewer that interprets the output encoding accurately).

BUT the problem may reside in your use of <xsl:value-of select="text()" />
rather than <xsl:value-of select="." />.  If you replace "text()" with ".",
and try it with MSXML3 (September), then you get what you expect.  This is
probably because MSXML3 makes an internal DOM that looks something like:

+- element SPA
   +- element PRODUCT
      +- text ALDARA
      +- text &#8482;
      +- text  5% CREAM

In other words, the text content of the PRODUCT element is split into three
because of the use of the entity.  When you do <xsl:value-of
select="text()" /> it gives the string value of the first text() node: in
this case just "ALDARA".

I think that MSXML is wrong to do this, at least with regards to the
interpretation of XPaths if not in the construction of the internal DOM.
The XPath spec says:

"Character data is grouped into text nodes. As much character data as
possible is grouped into each text node: a text node never has an
immediately following or preceding sibling that is a text node."
[http://www.w3.org/TR/xpath#section-Text-Nodes]

There aren't such things as 'entity reference nodes' within the XPath Rec
(even though there are entity reference objects under the DOM Level 1
Specification).

Anyway, Lee, you're probably much better off using <xsl:value-of select="."
/> in most cases anyway, because it will ignore any element content in
constructing the string value, which is generally a good thing.

Hope that helps,

Jeni

Jeni Tennison
http://www.jenitennison.com/


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.