Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Xstream/Stax integration

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Wolfgang Hoschek <whoschek AT lbl.gov>
  • To: Elliotte Harold <elharo AT metalab.unc.edu>
  • Cc: xom-interest <xom-interest AT lists.ibiblio.org>
  • Subject: Re: [XOM-interest] Xstream/Stax integration
  • Date: Wed, 24 Aug 2005 12:30:18 -0700

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.





Archive powered by MHonArc 2.6.24.

Top of Page