XOM API for Processing XML with Java

[Elliotte Harold <elharo AT metalab.unc.edu>]

Wolfgang Hoschek wrote:

> 1) as a seamless polymorphic substitute for SAX: One would like to  
> replace SAX with Stax while requiring as few code changes as  
> possible. This relegates Stax vs. SAX to an implementation/ 
> configuration decision. XOM design patterns should be closely  
> followed. For example Stax exceptions should be wrapped into XOM  
> ParsingException, StaxBuilder/Serializer should subclass or implement  
> common XOM interfaces.

I don't know that it really needs to be seamless, but this is the only 
use case I can really see. That would be contingent on a StAX parser 
being as robust and reliable as the best SAX parsers and a noticeable 
improvement in the speed department. So far StAX hasn't reached that 
level of maturity. Speed wise I can believe it might become as fast as 
SAX, but I don't think it's there yet; and I'll be surprised if it ever 
passes SAX by any significant amount.

The main advantage to StAX is simply that some developers prefer its 
Iterator-pattern design to SAX's Observer-pattern design. Beyond that, 
though, I don't think there's anything fundamentally better (or worse) 
about StAX compared to SAX. Since XOM already works with SAX, and since 
SAX is better tested, I'm not inclined to rip out the SAX dependence.

> 2) as a simple workaround that enables reading/writing from and to  
> Stax, in case there's no SAX API available: Consistency with existing  
> XOM design patterns isn't required. Getting the job done counts. How  
> it's done is secondary, as is to what extent it's complete, as long  
> as it's good enough to do XYZ. Makes sense, but probably not as part  
> of XOM core.

The only scenario where I can see StAX being present and SAX not being 
present is in J2ME. However, XOM really isn't going to work in J2ME. 
It's just too heavyweight. In such an environment, you'd use straight 
StAX, not StAX+XOM.

> 3) As a full pull parser API exposing Stax's nextXYZ() methods at the  
> XOM level: Part of the original simplicity/efficiency incentive for  
> Stax in the first place. The current API would need to be extended to  
> take account of this. Your current API converts a pull API into a  
> NodeFactory based push API - somewhat counter intuitive to folks  
> looking for pull style parsing at the XOM level. A true pull API  
> would be different than any current XOM API.

Pull APIs feel to me like a substitute for the full tree API of a model 
like XOM/JDOM/DOM. If you have a full multiway tree in memory already, 
why do you need a limited one-way pull API like StAX? Perhaps some sort 
of NodeIterators and NodeFilters like DOM's might occasionally be 
useful. However if that's what you wanted, I think a design like that 
would probably make more sense than StAX. StAX is designed primarily as 
a parsing API, not a generic tree traversal API.

My tentative feeling is that if StAX becomes widely popular (something I 
haven't seen happen yet) then I would add a StAXConverter class or some 
such to the nu.xom.converters package, just for convenience. However, 
the core of XOM including the Builder class is likely to continue 
depending on SAX.

--
Elliotte Rusty Harold  elharo AT metalab.unc.edu
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim