XOM API for Processing XML with Java

[Dan Diephouse <dan AT envoisolutions.com>]

Wolfgang Hoschek wrote:

> > 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.
Easy enough. I was dealing with SOAP so I skipped those.

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

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

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

Sure thats added easily enough.

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

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

- Dan

--
Dan Diephouse
Envoi Solutions LLC
http://netzooid.com