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: Elliotte Harold <elharo AT metalab.unc.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 09:43:47 -0500

John Cowan wrote:

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.

I think I'm following a variation of 1. The nodes are grouped before being passed to the XPath engine and ungrouped on return from it. It's all completely transparent to the public API. Clients never need to think about this. If I didn't ungroup what would come back would be something that was not in the original tree.

I think I see your point about wanting to know the boundaries of the XPath text nodes, even if they don't line up with XOM boundaries. (XOM should have a boundary wherever XPath does. It's just that XOM may have some extra boundaries as well.) I'm not sure I see the use case though. What sort of queries would make it useful to know the XPath boundaries?

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

I've considered this at various times. It's not hard to write. So far I haven't been convinced it's a common enough need to be justified as part of the core API, especially since it's easy enough to write as a static utility method and such a method is already present in the samples package. I might be convinced otherwise if I saw the need to do this coming up frequently. However, the only time I've actually needed this is in XPath, and I've now got an alternative implementation that doesn't require that. A lot of the use cases for this I've seen in DOM are better addressed in XOM by the getValue() method.

--
Elliotte Rusty Harold elharo AT metalab.unc.edu
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim




Archive powered by MHonArc 2.6.24.

Top of Page