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: Wolfgang Hoschek <whoschek AT lbl.gov>
  • To: shirasu hiroyuki <hirsh AT s9.dion.ne.jp>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] XOM 1.1: XPath
  • Date: Thu, 6 Jan 2005 20:34:36 -0800

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.





Archive powered by MHonArc 2.6.24.

Top of Page