XOM API for Processing XML with Java

[Laurent Bihanic <laurent.bihanic AT atosorigin.com>]

Hi,

You may be interested in looking at a contribution I made to JDOM: 
ElementScanner (in package org.jdom.contrib.input.scanner in the jdom-contrib 
CVS module). It does kind of what you propose.

Basically ElementScanner is an XMLFilter on which you register listeners 
associated to XPath-like expressions. When an element matches one of the 
registered XPath expressions, ElementScanner builds the element subtree, 
notifies the associated listener(s) and... forget about this element so that 
the garbage collector can free the memory.

With ElementScanner, your code looks like:
   ElementScanner f = new ElementScanner();
   f.addElementListener(myListener, "/doc/*");
   f.parse(new InputSource("test.xml"));

With myListener an instance of a class that implements ElementListener:
   public void elementMatched(String path, Element e) throws JDOMException;

ElementScanner converts the XPath-like expression into regular expressions for 
fast matching. Benchmarks show that the overhead, compared to the regular SAX 
Builder, is only 10% when building the whole document.

ElementScanner can easily be converted to XOM once the XOMHandler class made 
public.

Laurent


John Cowan wrote:
> Shemp is a concept (which should be very easy to code up) loosely based
> on Simon St. Laurent's MOE (http://moe.sourceforge.net), but using SAX
> and XOM instead of something special-purpose.  I will sketch it here
> and lazily let someone else fill in the details:
>
> Shemp is an XMLFilter, so you wrap it around some existing SAX parser.
> Normally, it just does what XMLFilterImpl does: it passes through each
> event from the wrapped parser to its client.  But during a startElement
> event, the client can invoke Shemp's constructElement method.  This sets
> an internal flag such that Shemp absorbs all events and manufactures
> XOM nodes starting with an Element node until the matching endElement
> event is seen.  This event within it is then passed to the client,
> who can invoke getElement to retrieve the XOM tree that Shemp has built.
>
> Shemp allows XOM to be used for documents that are too large to represent
> as a single xom.Document tree.  As soon as a suitable local root element
> is found, invoking constructElement will create a small XOM tree which
> can be passed from endElement to a XOM-aware portion of the program that
> can process it.  This would be useful, for example, for processing log
> files: only a single log entry would need to be in memory at one time,
> not the whole file.