XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

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