XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

> The code is very simple. If you get a START_ELEMENT you create an  
> Element, etc. I don't know that there is a whole lot of room to  
> mess up. I've used the code in the past, but am not using it right  
> now only because my project is included in an Apache project and  
> they aren't down with the LGPL.

It would help to have actual users of the code; it's the best way to  
identify and shake out issues that may be there.

> Even if there were bugs in it, they'd be minor.

The most likely source of bugs would probably be 1) in the underlying  
stax impl, and 2) the way your code interacts with potentially  
varying behaviour of those impls (they may not quite behave  
identical, the specs may leave wiggle room for interpretation, etc.).  
Dealing with bugs that may (or may not) be lurking in corners of your  
own code would be probably be easiest.

> All that to say, I think the code is pretty stable/reliable, I'm  
> just not using it at the moment. I'd be very interested in  
> performance of Stax vs. SAX in XOM and how the different stax  
> implementations compare if you'd be willing to run it through.

Apart from the core functionality, there's the public API design of  
the relevant classes. How configurable? How simple? How extensible?  
Inherently safe or potentially abusable? I don't know the answers,  
and I don't know Stax well enough, but I wouldn't be suprised to see  
initially rapid evolution in this area, followed by a stabilization  
phase.

For example, it brings up the question of the public XOM Builder API.  
Should the Stax builder be a) standalone, or b) a subclass, or c)  
implement some currently non-existing common interface? In case b)  
some methods in the XOM Builder might need to be made protected  
rather than private.

Wolfgang.