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 16:29:24 -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.


On a first quick glance over build(), it seems to also need to deal with comments and DocType as direct children of a document. The serializer needs to deal with those as well. Processing instructions would need to be dealt with as well.

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

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

Should there be a way for a user to get a default (or preferred) Stax impl, for example in noargs constructors? Along the lines of the XOM Builder selecting preferred SAX parsers.

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.

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

Wolfgang.





Archive powered by MHonArc 2.6.24.

Top of Page