XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

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