XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

> Elliotte Harold writes:
>
> > 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. 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? We
> > might need to change that too so that if it saw consecutive text nodes
> > it accumulated them into a list before wrapping, rather than wrapping
> > each one individually.
>
> One of the advantages of using XPath with XOM, JDOM is you can
> manipulate the nodes in the result set to modify the original document.
> Otherwise you may as well just feed the XPath engines with a SAX 
> converter
> and receive results with a SAX builder.  If 3 adjacent text nodes are 
> wrap,
> I'd hope I could do things like a single detach and all 3 nodes would 
> be
> detached from the original document. So would wrapping adjacent text 
> nodes
> in a special subclass of nu.xom.Text before feeding it to Saxon, 
> Jaxen, etc.
> work instead of tring to modify the internals of every engine that 
> comes
> along?
>
> Brad

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?

Should it be null? Seems wrong since the query is asking for nodes 
contained in the tree, not a free standing node.

Should it be the parent node of the adjacent text nodes? If so the 
parent must have the non-merged text nodes plus the merged text node as 
children, because parent and child are always double linked in XOM. But 
that doesn't make much sense. For example, what would 
Element.indexOf(text) then yield? Plus, adding nodes is forbidden 
anyway as XPath is a read-only model.

Thus, I continue to think that an explicit ParentNode.normalizeTexts() 
is the best way, if any. This approach is easy to understand, works, 
and few real use cases needs the text merging functionality anyway.

Perhaps there's a good reason after all that MSXML doesn't handle it 
either, and noone seems to have had an issue with Saxon's behaviour so 
far, as Mike reported.

Wolfgang.