Bob Hutchison wrote:

> 0) parse an XML document and generate SAX-like events without having to
> have the whole document in memory. (I'm getting boring :-)

REXML does this; I suspect NQXML does this, but Jim will have to comment on 
it.  XMLParser does it the way expat does it, whichever way that is.

> 0.1) parse an XML document and generate a DOM-like structure [I would
> never use this, personally, but I think others want it].

REXML, NQXML, XMLParser: yes.

> 0.2) write an XML document using an event-like api.

Could you elaborate?  I think I know what you mean, but it'll be less work 
if I don't start making assumptions.  I'm used to creating DOM-like 
documents, and then writing them out; I don't use SAX-ish interfaces much, 
so you'll have to be more explicit.

> 0.3) write the XML corresponding to the DOM-like structure.

REXML, NQXML: yes.  
XMLParser: ?

> Given that this is Ruby, I'd say ease of use has to rank up there.

Absolutely.

>> Would several tools (each adapted to a different use) be better than one
>> mondo tool?
> 
> Again, this strikes me as being more Ruby-like.

Unless you want to have a lot of duplicated code, you're going to have to 
have a base parser.  EG, tacking on stream parsing to REXML was pretty 
easy, because most of the parsing code was already there for tree parsing.

Now, I've been increasingly detaching XPath from the core parser in REXML, 
although REXML depends heavily on XPath for convenience methods.  I've been 
considering how to implement a validating parser, and I think that if I 
ever do it, it'll be detached from REXML, so that VParser depends on REXML, 
but not vice versa.  This is important to me too keep the speed constant as 
we add functionality.

-- 
--- SER