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

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.





Archive powered by MHonArc 2.6.24.

Top of Page