XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

On Aug 24, 2005, at 3:15 AM, Elliotte Harold wrote:

> 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.

Assyume a Builder object is passed through various layers of a XOM  
app (e.g. a BuilderPool or DocumentFactory). One wouldn't want to add  
separate classes and methods for dealing with Stax, multiplying API  
complexity. It would be preferrable to have the Stax and SAX Builder  
implement the same interface, so that no change at all would be  
necessary.

> 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.

I wouldn't be surprised if the results turn out to be as you say. But  
then again, we don't know yet.

> 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.

Sure, there's no need for changing XOM and it's SAX usage. There may  
perhaps be a need to add some common interfaces to fit in Stax more  
seamlessly, but nomore than that.

> > 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.

My impression is that this thread started out because new tools such  
as Axis2 and XFire only expose Stax interfaces, but no SAX interfaces.

> > 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.

The primary motivation for a pull API at the XOM level would be the  
same as for Stax vs. SAX: somewhat simpler filtered pull streaming,  
avoiding the need to build a full main memory tree. Since XOM already  
has a rather convenient streaming API (push NodeFactory), I don't  
know if there's a compelling need for a pull equivalent. However, a  
design probably shouldn't preclude adding something like that at some  
later point.

> 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.

Makes sense.

Wolfgang.