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: Dan Diephouse <dan AT envoisolutions.com>
  • Cc: xom-interest <xom-interest AT lists.ibiblio.org>
  • Subject: Re: [XOM-interest] Xstream/Stax integration
  • Date: Tue, 23 Aug 2005 14:11:18 -0700

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.




Archive powered by MHonArc 2.6.24.

Top of Page