Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Shemp: an XMLFilter for use with XOM

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Laurent Bihanic <laurent.bihanic AT atosorigin.com>
  • To: John Cowan <jcowan AT reutershealth.com>
  • Cc: Xom Interest <xom-interest AT lists.ibiblio.org>
  • Subject: Re: [XOM-interest] Shemp: an XMLFilter for use with XOM
  • Date: Tue, 24 Sep 2002 10:31:51 +0200

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.





Archive powered by MHonArc 2.6.24.

Top of Page