XOM API for Processing XML with Java

[John Cowan <jcowan AT reutershealth.com>]

Elliotte Harold scripsit:

> Good point, though it's actually the unorderedness of the set that's 
> tricky here. I'll have to look at the API and implementation but I think 
> I can guarantee that at an absolute minimum the XOM Text objects making 
> up an XPath text node do not get reshuffled. That is, they will be 
> returned in the same order they appeared in in the input document.

I think so too; the theoretical freedom of an XPath engine to return
XPath nodes in any order is unlikely to be exercised, since most XPath
engines are meant to work with XSLT, which insists on document order.

Still, just because you *can* reconstruct exactly what the XPath nodes
are from the Nodes object returned by XOM 1.1 doesn't mean that it's
easy without some further assistance from the API.

I think on the whole that the most "XOMmy" thing to do is to create a new
subclass of ParentNode called XPathText, which is a typesafe container
for Text Nodes. In the normal case (only one Text Node per XPath node)
these would not be needed, but people calling the XPath API would have
to be prepared to deal with them.

There are three plausible implementation strategies: group the nodes
before sending them to the XPath engine, group them on return from the
engine, or insert and remove XPathText nodes behind the scenes from the
tree itself during ordinary XOM operations, taking pains to hide them from
the regular API.  The third trades off implementation pain for run-time
efficiency, and IMHO isn't worth it.  I think the first strategy wins.

In any case, a ParentNode.normalizeTextNodes API should be provided,
as it is useful outside XPath as well.

-- 
Values of beeta will give rise to dom!          John Cowan
(5th/6th edition 'mv' said this if you tried    http://www.ccil.org/~cowan
to rename '.' or '..' entries; see              jcowan AT reutershealth.com
http://cm.bell-labs.com/cm/cs/who/dmr/odd.html)