XOM API for Processing XML with Java

[Laurent Bihanic <laurent.bihanic AT atosorigin.com>]

John Cowan wrote:
> With just a few more methods, it would be easy to make SAXConverter implement
> org.xml.sax.XMLReader, which would make it much more valuable in large
> programs where you may want to provide an existing component with SAX events.

Although most XMLReader methods could be added and mapped nicely to existing 
SAXConverter methods, the 2 parse() methods don't fit. They would force XOM to 
provide a SAXConverter-specific InputSource implementation wrapping a XOM 
document.

A possible solution would be for SAXConverter to provide a public no-arg 
constructor and 2 factory methods makeXMLReader() and 
makeInputSource(Document), returning instances of private inner/nested 
classes. That way any subclass of SAXConverter could be converted into an 
XMLReader for free and the SAXConverter interface will be kept as simple as 
possible.

> DOMConverter should really be part of Builder; this would simplify the
> architecture.  However, it would also require carrying around the
> org.xml.dom interfaces with XOM all the time, which might be thought too 
> expensive.

-1 (as I never use DOM, the lighter the better)

Laurent