XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

> > OK. I've looked at the code and it seems like we could wrap
> > an array or
> > list of several Text objects as a single SAXON Node.
>
> Yes, it's certainly doable in principle.

I haven't tried implementing some such, but I suspect it would be quite 
a bit more tricky (and confusing and slow) than it appears at first 
glance.

Given Brad's comments about historic JDOM versions causing confusion on 
auto-merging text nodes on insert/remove, and given Eliotte's comments 
confirming that adjacent text nodes can only be generated by certain 
(rather uncommon) situations on remove() and to insert(), I think that 
either

a) XOM should have a method "public void ParentNode.normalizeTexts()" 
doing text merging. A user that wants to be sure should call that prior 
to XPath queries. That way there is no confusion as to what's 
happening, all code keeps being simple and straightforward, and the 
performance penality is minimized.

or

b) Saxon should filter things out at a higher level, independent of the 
underlying object model. Unfortunately this might be the most expensive 
option.

I'm leaning towards a)

Wolfgang.

> > However, I'm not
> > sure how we'd feed the document into SAXON inn the first
> > place. Where's the class that reads through a XOM Document and wraps
> everything?
>
> That's not the way it works. The wrappers are created on demand. You 
> start
> by creating a wrapper for the Document node and supplying that as a 
> Source
> object to Saxon. Then when any XPath expression navigates from that 
> Document
> node, or from any other wrapped XOM node, it creates wrappers for the 
> nodes
> that it finds, and returns those wrappers. To reduce the cost, a node 
> that
> is reached by downward selection retains a reference to the wrapper 
> for its
> parent, but in other cases no attempt is made to reuse the wrappers 
> when the
> same node is accessed multiple times (I did some experiments a long 
> time ago
> that led me to do it that way, though the results are not necessarily
> conclusive today: it's based on the premise that in a typical XSLT
> transformation each node is touched about once.)

To get a quick start, look at the source code for nux.xom.XQuery. This 
is the class where all processing starts.

> > This might require some changes to Saxon internals but it should help
> > out with JDOM as well. What about DOM? Does SAXON also not merge
> > adjacent text nodes there?
>
> The same problem applies to JDOM and DOM. I would probably handle it 
> through
> another level of VirtualNode, which could be used by all three 
> mappings.
>
> Michael Kay