XOM API for Processing XML with Java

[Hallvard Trætteberg <hal AT idi.ntnu.no>]

Hi,

I've been following the discussion about XOM, XPath and Nux/Saxon with great
interest, both because it's interesting software-wise and because I'm
interested interested in the result. I've previously used Jaxen with JDOM
and I've contributed XOM support for Jaxen (based on the JDOM code), so I
understand many of the problems of bridging between an XML tree
representation and an XPath engine.
BTW, I've recently ditched Jaxen in favor of Nux/Saxon, because Jaxens has
too many bugs and Saxon in addition gives me XSLT.

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.

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.

Hallvard

> > I disagree. I think output 1 is clearly correct. Anything else is 
> > suboptimal. If a user is confused by output 1, then it is because they 
> > are confused by XPath and the unfortunate impedance mismatch between 
> > XPath and XOM. The more I think about this the more I'm convinced that 
> > output 1 is right.
> 
> Well, it would be helpful if you could state why this is "clearly 
> correct".
> 
> I'll add the following method to the next Nux release 
> candidate, unless a convincing argument can be made that one
> can easily do without it:
> [...]
> public static void normalizeTexts(ParentNode node) {