[jdom-interest] Re: Proposal: JDOM event based processing

[James Strachan]

----- Original Message -----
From: "Patrick Dowler" <Patrick.Dowler at nrc.ca>

[snip]

> There was some talk about reworking JDOM so that you did "lazy" reading
> to an extent (buffered the input rather than reading the whole document).
It
> seems to be a necessity for handling large XML files. It would also be
good
> for any application that will make one pass through the Document:

Sure and the ElementHandler proposal is my attempt to make the 'lazy'
reading happen.

We need some kind of contract to determine what SAX events get constructed
into what Element trees for processing. So my proposal was XPath expression
+ ElementHandler on a new kind of SAXBuilder called SAXProcessor.

> I think a LazyDocument wouldn't be trivial to write since an Element
(subtree)
> can have arbitrary size... at first glance it appears that the live part
of the
> document would vary in size. Maybe the caller would have to explicitly
> discard fragments when they were done (an Iterator type of thing comes to
> mind: next() could discard the last fragment and process the next one).

Agreed, doing it at the LazyDocument layer would be hard. Which is why I'm
advocating using a SAX based XMLFilter approach to 'route' SAX events using
XPath expressions to an ElementTreeBuilder which then passes the constructed
object on to an ElementHandler. i.e. up front you decide what sub trees you
are interested in before parsing commences.