XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

> 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.