Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] XOM 1.1: XPath

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: "Bradley S. Huffman" <hip AT cs.okstate.edu>
  • To: John Cowan <jcowan AT reutershealth.com>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] XOM 1.1: XPath
  • Date: Wed, 12 Jan 2005 08:55:03 -0600

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




Archive powered by MHonArc 2.6.24.

Top of Page