XOM API for Processing XML with Java

[Wolfgang Hoschek <wolfgang.hoschek AT mac.com>]

On Jan 20, 2006, at 2:31 PM, Wolfgang Hoschek wrote:

> On Jan 20, 2006, at 2:05 PM, Elliotte Harold wrote:
>
> > Wolfgang Hoschek wrote:
> >
> > > Bottom line: I don't think XOM can or should do something about
> > > this problem.
> >
> > Possibly. I am considering whether I could add an extra protected
> > method  to NodeFactory that would be called once for each
> > invocation of characters() by SAX and which would enable such
> > buffering. Currently XOM has to buffer in XOMHandler anyway. It
> > might be possible to move this into NodeFactory.
>
> I guess there's no SAX property that would force the underlying
> parser to limit character() chunks to <= X bytes. So no guarantee can
> be given that an OOM error can be avoided. Even if there's no error
> with parser X today, it might be different with a different parser,
> or with a different version.
>
> Plus, what about very large base64 comment nodes?
>
> I still believe that such an unusual use case is best dealt with by a
> custom SAX content handler, rather than at the XOM level. Too much
> additional complexity for too little additional value.


I should add that if the MIME/multipart route doesn't apply, then  
STAX/Woodstox may well be a more natural fit for this scenario than  
SAX. In particular via the STAX method  
XMLStreamReader.getTextCharacters(int sourceStart, char[] target, int  
targetStart, int length).

My local Nux devel version already has production quality STAX  
support for XOM. In a nutshell it contains:

1) a facility to write XOM documents to a STAX XMLStreamWriter  
(StreamingSerializerFactory)
2) a subclass of nu.xom.Builder that has the same behaviour as the  
XOM Builder, except that it runs over STAX (StaxUtil.getBuilder())
3) a class that allows to build XOM documents, fragments, nodes, etc,  
from STAX, with or without a NodeFactory (StaxParser)
4) a class that makes a XOM tree appear as a STAX XMLStreamReader  
(StaxUtil.asXMLStreamReader(ParentNode))

Option 3) most closely applies to the large base64 case, enabling a  
client to call XMLStreamReader.getTextCharacters(...) directly  
without any XOM interference.

Wolfgang.