Re: DOM Level 3 XPath Specification and entity references

The idea is that since you're calling XPath in the DOM world, you get a
result in terms of the DOM tree.

If the XPath returns text, it returns only first Text/CData node in any
block of logically-contiguous text. (Which may involve multiple nodes, and
may cross EntityReference boundaries.)

A separate convenience function allows querying all the
logically-contiguous text as a single string, ant it's the API user's
responsibility to understand that when a Text node is returned they should
use this approach rather than just asking that node for its own data/value.

(Or, of course, the user can set up their own iterator/treewalker to
examine the consecutive nodes, if they really care about the structure. We
might want to include an appropriate NodeFilter in our documentation,
though I think that would be considered to be on the wrong side of the
declarative/descriptive line.)


It's a compromise to match impedence between the XPath and DOM data models.
I consider it a reasonable one, since anyone who wants only the XPath view
can fairly easily derive that from these tools,, while those who want the
DOM view still have the additional detail available.

(If XPath and DOM hadn't diverged, this kluge wouldn't be necessary. But
they did, and we're stuck with trying to come up with a reasonable
interpretation and implementation despite that..)

______________________________________
Joe Kesselman  / IBM Research

Received on Wednesday, 10 October 2001 11:01:49 UTC