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: Elliotte Harold <elharo AT metalab.unc.edu>
  • Cc: "'Bradley S. Huffman'" <hip AT a.cs.okstate.edu>, xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] XOM 1.1: XPath
  • Date: Sat, 8 Jan 2005 16:24:46 -0800


You need to think in terms of two views: the XOM view, and the XPath view.
The merged node appears only in the XPath view, it should never be visible
in the XOM view. An XPath expression that finds the merged node should
return the first corresponding text node back across the API, it should not
make the merged node visible. This way, both views of the tree are
consistent in their own terms.

Yep, but problems arise on output where the views are brought together in one way or another. How should the text nodes in the result sequence look like? More below...


Agreed, except that it should return all the corresponding text nodes back across the API, not just the first one. That is if XPath text node A is made up of XOM Text objects t1, t2, and t3, then an XPath expressions that matches text node A will return a Nodes object containing t1, t2, and t3 in their original order.

Either that (output 1), or a list with a single XOM text node having no parent, containing the concatenation of t1, t2 and t3 (output 2). The problem is that neither output is satisfactory from a certain angle. The only really satisfactory output would be a single XOM text node having the parent of t1, t2 and t3, containing the concatenation of t1, t2 and t3 (output 3). But output 3 isn't possible with XOM unless the texts were merged before passing them into XPath because XPath is a read-only model.

A user might expect output 1, 2 or 3 when matching on text = "helloworldnux", depending how he looks at the problem. What do we do? Any ideas what other engines output when running over external tree models?


The more i think about the adjacent text node issue the more i think i can't be handled cleanly inside an XPath impl running over XOM, even if one wanted to handle it. If an XPath impl merges text nodes into a virtual (but not actual) text node, what's the XOM parent node of that virtual text node?

The more I think about this the more I'm convinced this is not a theoretical problem; i.e. it should be doable.

It's theoretic to an extent because a real use case coupled with the problematic situation of adjacent text nodes seems to hardly ever come up, not because it's hard to implement.

There may be implementation issues inside th XPath engine, but there's no fundamental reason an XPath engine shouldn't be able to handle this.

To answer the specific question you ask, the parent of the virtual node is the parent of the text nodes that comprise the virtual node.

All we need to do to make this work (in theory, implementation details could be tricky) is add one additional layer between XOM and Saxon/Jaxen/etc., which we need anyway. I'm not explaining myself very well here (haven't had my morning coffee yet) but I really think it's doable and much more consistent and easy to explain than the alternative. It's harder to implement, but I do think it's worth implementing.

The question right now probably shouldn't be how we do it, but more what do we expect as output under which circumstances?

Wolfgang.





Archive powered by MHonArc 2.6.24.

Top of Page