From: Ross Bamford <rossrt@...>
Date: 2006-10-22T19:41:09+09:00
Subject: Re: One more way to parse XML...

On Sun, 2006-10-22 at 04:30 +0900, pete@jwgibbs.cchem.berkeley.edu
wrote:
> In article <1161423290.5377.28.camel@localhost.localdomain>,
> Ross Bamford  <rossrt@roscopeco.co.uk> wrote:
> >On Sat, 2006-10-21 at 16:15 +0900, pete@jwgibbs.cchem.berkeley.edu
> >wrote:
> >> I thought I'd put this out to see if there's any interest.
> >
> >This looks pretty cool. It has echoes of the Jakarta Commons Digester,
> >of which I made a Ruby port a while back (http://digestr.rubyforge.org),
> >though using libxml-ruby rather than REXML. 
> 
> Hmm, yes.  I hadn't come across the "digester" before, but there
> do seem to be parallel trains of thought there.  (I looked through the
> Jakarta version rather than yours -- finding a magazine article to
> read is more comfortable than chugging through documentation!)
> Looks nice (and much more extensive than mine, of course).
> 

Yes, it is pretty useful in some cases. The Ruby version is rather
trimmed down by the standards of the Java one, partly because Ruby gets
more done with less code, and partly because I didn't need everything
when I made the port :)

> The main difference (in philosophy) seems to be that the digester
> describes the tree with complete absolute paths for each node, where
> my scheme has each node only knowing about its immediate descendants.
> 

Ahh, I see. That's an interesting strategy (certainly would be easier to
get on with, esp under refactoring which can be a nightmare). I'll have
to have a closer look at your code.

> >I quite like the digester model and have found it very handy for dealing
> >with certain types of XML (mostly XML from the Java world I guess).
> 
> The article I read did seem to be oriented to building a tree (of Beans)
> in memory (so aren't we sort of back to DOM?) but I gather that you can
> provide other custom methods to do other kinds of processing.
> 

Yes, most of the standard rules are geared towards building DOM-like
trees, though instead of a tree representing the XML they allow an
arbitrary tree of objects to be built based on the XML, with rules to
take object attribute values from XML attributes, tag bodies, and so on.

You can just plug in your own rule implementations to do pretty much
what you like - they're basically just SAX handlers (at least in the
Ruby implementation, IIRC there's a bit more abstraction in the Java
original).

Cheers,
-- 
Ross Bamford - rosco@roscopeco.REMOVE.co.uk