XOM API for Processing XML with Java

["Bradley S. Huffman" <hip AT cs.okstate.edu>]

John Cowan writes:

> 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.

But if it's a subclass of ParentNode, it's also a subclass of Node, so I
can detach it and try to re-insert it someplace else, which means the
core class are going to have to compensate for this special class. Sounds
real messy.

> 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.

Or drop the restriction that a query return only a instances of Nodes and
allow it to return a instance of Boolean, String, or Node, then have a wrapper
class that *is not* a instance of any XOM core class that wraps Text nodes on
input and let it pass right though to the result.

    public interface TextSequence {
        ParentNode getParent();
        Document getDocument();
        int getIndexOfFirstNode();
        int getIndexOfLastNode();
        void detach();
        String getValue();
        void setValue(String data); // replace all nodes with a single Text 
        Node copy(); // returns a single Text
        void replace(Node node);
    }

Brad