DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4908>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4908 XPath's text() and node() selectors get confused by CDATA sections ------- Additional Comments From [EMAIL PROTECTED] 2001-11-16 12:26 ------- At a quick glance, I think the problem's in ApplyXPath. This sample's based on applying the XPath to a DOM, so we're using DOM2DTM. That means that when you ask for /doc/text()[2], we attempt to return it in DOM terms. As discussed, a block of successive text/cdata nodes in the DOM is treated as a single XPath text node, and when XPath returns that as a DOM location it does so by returning a pointer to the first such node. That's working as designed, and because the DOM and XPath data models really aren't in complete ageement with each other, it really is the most accuate answer we can deliver. The problem is that when ApplyXPath goes to serialize this out for display to the user, it isn't checking whether there are additional DOM nodes following this one -- "logically adjacent text" -- that would be part of the same XPath response and should also be serialized out. It's just dumping that one DOM node, and dumping it _as_ a DOM node. If we want ApplyXPath to display all the contents of an XPath (as opposed to DOM) text node, we need to fix it to perform that check. If we want to display only the text, we need to tell it to do that too. (See also http://www.w3.org/TR/2001/WD-DOM-Level-3-XPath-20011031/xpath.html#TextNodes for more discussion of the issues of applying XPaths to DOMs. Their current draft actually returns the first non-empty text node in the sequence; I'm unsure whether that's really an improvement or not.)
