XOM API for Processing XML with Java

[Elliotte Harold <elharo AT metalab.unc.edu>]

Hallvard Trætteberg wrote:


> For me the big advantage of integrating XOM with an XPath engine is being
> able to operate on the result set as ordinary XOM objects. I.e. I know they
> come from my own XML document tree, I know they have the expected parent
> child relationship and I know operating on them may change the XML document
> itself (unless I explicitly clone nodes/elements). In my experience, the
> problem of having text split into several text nodes is a problem that the
> programmer needs to be aware of and handle, disregarding the use of XPath.
> Introducing virtual nodes for XPath's sake is more consfusing than helpful,
> since it cannot create the illusion of a proper XOM node. If they are used
> as part of the result set they cannot be operated upon as normal XOM nodes,
> as they are not part of the XML document. On the other hand, if they are
> unwrapped into a set of text nodes (in the result set), I will not be able
> to know if each text node matched the XPath individually or as a sequence.
> Suppose I had the following XML <p>abra is part of <b>abracadabra</b></p>
> and "abracadabra" was split into three text nodes "abra", "cad" and "abra".
> I run an XPath for finding "abra" and would get four text nodes in the
> result. I would have to include logic for sorting out that these are two
> logical text nodes, even if there are four of them and three of them matched
> the XPath. The easiest way out would be to ensure that no text nodes are
> split.

Could you expand on this point with an actual use case, not a 
theoretical one?

> My point is that the programmer will have to understand this problem and
> that this cannot be handled automatically by a XOM XPath api in a clean way
> (not by auto-merging, not by including virtual nodes). The most helpful
> support is Wolfgang's suggestion as shown below: a normalizeTexts method.

I think a lot of people just aren't understanding what Michael Kay and I 
are trying to say. Let me try to be really clear about that:

1. No auto-merging of text nodes
2. No client-visible virtual nodes

Every XPath Query will return a list of nodes selected from the original 
document. None of these will have been changed in any way.

The only issue is when you do a query that specifically matches against 
text() nodes (not element values, but actual text nodes) or count the 
number of children of an element and try to match positions, whether 
adjacent text nodes count as one thing or several things. That's it.

Does that satisfy you?

--
Elliotte Rusty Harold  elharo AT metalab.unc.edu
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim