Subject: RE: Saxon and MSXML3 differences From: Andrew Kimball <akimball@xxxxxxxxxxxxx> Date: Thu, 26 Oct 2000 12:02:41 -0700 |
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 ™ 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 ™ +- 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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Saxon and MSXML3 differences, Lee Goddard | Thread | RE: Saxon and MSXML3 differences, Kay Michael |
MSXML3.0 and Java, John Palmisano | Date | Re: [Fwd: Java error with new XALAN, Gary L Peskin |
Month |