Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] RE: XPath support in XOM

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: Hallvard Trætteberg <hal AT idi.ntnu.no>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] RE: XPath support in XOM
  • Date: Mon, 10 Jan 2005 05:49:10 -0500

Hallvard Trætteberg wrote:


For me the big advantage of integrating XOM with an XPath engine is being
able to operate on the result set as ordinary XOM objects. I.e. I know they
come from my own XML document tree, I know they have the expected parent
child relationship and I know operating on them may change the XML document
itself (unless I explicitly clone nodes/elements). In my experience, the
problem of having text split into several text nodes is a problem that the
programmer needs to be aware of and handle, disregarding the use of XPath.
Introducing virtual nodes for XPath's sake is more consfusing than helpful,
since it cannot create the illusion of a proper XOM node. If they are used
as part of the result set they cannot be operated upon as normal XOM nodes,
as they are not part of the XML document. On the other hand, if they are
unwrapped into a set of text nodes (in the result set), I will not be able
to know if each text node matched the XPath individually or as a sequence.
Suppose I had the following XML <p>abra is part of <b>abracadabra</b></p>
and "abracadabra" was split into three text nodes "abra", "cad" and "abra".
I run an XPath for finding "abra" and would get four text nodes in the
result. I would have to include logic for sorting out that these are two
logical text nodes, even if there are four of them and three of them matched
the XPath. The easiest way out would be to ensure that no text nodes are
split.

Could you expand on this point with an actual use case, not a theoretical one?

My point is that the programmer will have to understand this problem and
that this cannot be handled automatically by a XOM XPath api in a clean way
(not by auto-merging, not by including virtual nodes). The most helpful
support is Wolfgang's suggestion as shown below: a normalizeTexts method.


I think a lot of people just aren't understanding what Michael Kay and I are trying to say. Let me try to be really clear about that:

1. No auto-merging of text nodes
2. No client-visible virtual nodes

Every XPath Query will return a list of nodes selected from the original document. None of these will have been changed in any way.

The only issue is when you do a query that specifically matches against text() nodes (not element values, but actual text nodes) or count the number of children of an element and try to match positions, whether adjacent text nodes count as one thing or several things. That's it.

Does that satisfy you?

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