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 23:41:36 -0700

Easy enough. I was dealing with SOAP so I skipped those.

I think it should be able to deal with full XML.



Why is there a public writeElement() when there's no endDocument() to properly close?


Because I need to parse document fragments. I.e. I may only want to parse the SOAP headers and leave the rest of the SOAP document as a stream for processing via another tool. Thats part of the reason StAX is an enticing format for processing XML.

I mean why is there no public endDocument() in the serializer?



Same question as for the builder: should the Stax Serializer be a subclass of the XOM Serializer, or standalone, or implement some common interface?


I think its sufficiently different enough that it warrents its own way.

It seems to me that there are at least 3 usage scenarios for XOM/Stax:

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.

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.

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.



Overall, there are design consistency issues to deal with, considering the way things are currently exposed in XOM/SAX, and the way they might be exposed for XOM/Stax. For example, how to achieve the "same" indentation behaviour with Stax? That is, if that's deemed desirable. Are adjacent Text and CDATA nodes merged on build(), as they are in the XOM Builder?. How to layout and align parsing exceptions? It seems there'd be plenty more issues if one were to look at it closer.


Indentation is a non goal for me. Some parsers (i.e. woodstox) are working on an indentation engine so I think that should be skipped.

Makes sense.

As for layout/parsing exceptions I'm not sure what you mean.
XMLStreamReader/Writer only through the XMLStreamException. I believe that should handed back out to the user. In addition there are the normal invalid XML exceptiosn that XOM will throw already.

To wrap or not? as outlined above. XOM wraps SAXExceptions into higher level exceptions.



Bottom line, someone would need to put some real effort into it to get this into shape for consistent, reliable long-term inclusion.


Yes, there are few nitpick type issues. And that will come as more people look and give feedback. I don't really believe its as bad as you make it out to be. Your suggestions could easily be implemented in under an hour.

Sorry, I don't mean to be picky or make it sound bad. Rather, I'd very much encourage you to take it further, communicate the pros and cons of design decisions, and eventually turn it into a production quality contribution!

Wolfgang.





Archive powered by MHonArc 2.6.24.

Top of Page