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: Elliotte Harold <elharo AT metalab.unc.edu>
  • To: Wolfgang Hoschek <whoschek AT lbl.gov>
  • Cc: xom-interest <xom-interest AT lists.ibiblio.org>
  • Subject: Re: [XOM-interest] Xstream/Stax integration
  • Date: Wed, 24 Aug 2005 06:15:59 -0400

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




Archive powered by MHonArc 2.6.24.

Top of Page