Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] New XPath issue: what to do with non-nodes?

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: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] New XPath issue: what to do with non-nodes?
  • Date: Mon, 17 Jan 2005 10:36:00 -0600

Looks like the idea of having a subclass of Text that wraps a
sequence of Text nodes will work. What I did was modify SelfAxisIterator
and ChildAxisIterator in Jaxen's xom/DocumentNavigator to wrap all adjacent
Text nodes which then pass through Jaxen as a single node that looks to the
user as a ordinary Text node. The one exception is if you call
ParentNode.indexOf
on a wrapper node it always returns -1. But all the other methods in the API
that take a Node as a parameter treat it like any other Text node.

If you want to see the code, e-mail me.

This is another option, however I'm still not sure it is the best option.
One thing I don't like with this option is there are now two cases. The case
where you use xpath and things are done automatically, and the case where
you don't use xpath and you have to handle adjacent Text nodes yourself.
Currently if you see a sequence of adjacent Text nodes in the document,
they will be reflected "as-is" in the xpath result. Although dealing with
them may be a bit tricky, it is consistent.

So I'm still not sure leaving things the way they are and taking Wolfgang's
suggestion of a ParentNode.normalizeText(), or maybe the following static
convenience methods on Text

// return a single Text of adjacent Text nodes starting with parameter
public static Node copy(Text firstTextNode);
// detach all adjacent Text nodes starting with parameter
public static void detach(Text firstTextNode);
// xpath value of all adjacent Text nodes starting with parameter
public static String getValue(Text firstTextNode);
public static String toXML(Text firstTextNode);

wouldn't be a better option.

Brad




Archive powered by MHonArc 2.6.24.

Top of Page