XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

On Jan 6, 2005, at 7:05 PM, shirasu hiroyuki wrote:

> Elliotte Harold wrote:
> > How about this one. What does Nux return?
> >
> > Element elem = new Element("elem");
> > elem.appendChild("hello");
> > elem.appendChild("world");
> > elem.appendChild("nux");
> >
> > Nodes results = new XQuery("./child::*[2]", 
> > null).execute(elem).toNodes();
> > for (int i=0; i < results.size(); i++) {
> >       System.out.println("i="+i+":" + results.get(i).toXML());
> > }
> >
> > If XPath is properly implemented this should return an empty list. 
> > Does it?
>
> Do you mean "child::text()[2]" in your XPath expression?
> "child::*" select all element children, but not text nodes.
>
> For the XPath "./text()",
> We expect one text node with "helloworldnux",
> but Nux returns three text nodes.

As already mentioned, the saxon documentation describes why that is the 
case.

One could have a normalizeTexts(ParentNode) method that coalesces 
(merges) adjacent Text nodes of a subtree, if that's what really comes 
up in practical apps. Making such a tree mutation the built-in default 
does not seem a good idea because XPath/XQuery are read-only models - 
Nux/Saxon won't modify nodes passed to it in any way.

Adjacent text nodes probably don't come up often when assembling a XOM 
tree in memory, and I speculate that they also rarely comes up when 
getting a document from a (SAX) Builder.

Mike might be able to add a more thorough explanation.

Wolfgang.