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: "Michael Kay" <mike AT saxonica.com>
  • Cc: 'Elliotte Harold' <elharo AT metalab.unc.edu>, 'xom-interest' <xom-interest AT lists.ibiblio.org>
  • Subject: Re: [XOM-interest] XOM 1.1: XPath
  • Date: Fri, 7 Jan 2005 09:59:20 -0800


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





Archive powered by MHonArc 2.6.24.

Top of Page