XOM API for Processing XML with Java

["Michael Kay" <mike AT saxonica.com>]

I think Hallvard makes a good point. If there is a sequence of four adjacent
text nodes, containing the values "makes ", " a", " good", " point", then
the query:

.//text()[contains(., "o")]

is either going to return a set of four XOM text nodes of which only two
contain the letter "o" (if we return all the XOM text nodes corresponding to
the XPath text node that matched the expression), or it's going to return a
single XOM text node whose value is "makes" (if we follow the DOM level 3
XPath spec by returning the first). Either result is going to be rather
confusing.

By all means provide options to prevent multiple adjacent XOM text nodes
arising; but if this is only an option, an XPath engine still needs to do
something when the option hasn't been used.

In this case I think that Elliotte's solution of mapping one XPath text node
in the XPath result to all four corresponding XOM text nodes in the XOM
result is still probably the best option; at any rate, I haven't seen a
better one.

Michael Kay
http://www.saxonica.com/ 

 

> -----Original Message-----
> From: xom-interest-bounces AT lists.ibiblio.org 
> [mailto:xom-interest-bounces AT lists.ibiblio.org] On Behalf Of 
> Elliotte Harold
> Sent: 10 January 2005 10:49
> To: Hallvard Trætteberg
> Cc: xom-interest AT lists.ibiblio.org
> Subject: Re: [XOM-interest] RE: XPath support in XOM
> 
> 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
> _______________________________________________
> XOM-interest mailing list
> XOM-interest AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/xom-interest
>