XOM API for Processing XML with Java

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

On Oct 25, 2006, at 11:30 AM, Randall R Schulz wrote:

> Wolfgang,
>
> Thanks. Follow-ups below.
>
>
> On Wednesday 25 October 2006 10:59, Wolfgang Hoschek wrote:
> > RelaxNG, XOM and *SAX* can be combined via the Nux method
> > nux.xom.pool.BuilderFactory.createMSVBuilder(...).
> > See http://dsd.lbl.gov/nux/api/nux/xom/pool/BuilderFactory.html
> >
> > Example usage:
> >
> >  ...
> >
> > Alternatively, RelaxNG, XOM and *StaX* can be combined via the Nux
> > method nux.xom.io.StaxUtil.createBuilder(...) where XMLInputFactory
> > means Woodstox StAX configured to validate against RelaxNG. See the
> > woodstox documentation for examples, as well as See http://
> > dsd.lbl.gov/nux/api/nux/xom/io/StaxUtil.html
> >
> > Example usage:
> >
> >  ...
> >
> > Both SAX and StAX Builder implementations use the Sun-MSV validator
> > behind the scenes.
>
> I did also encounter Nux in my research. Beyond the fact that it uses
> XOM, it was unclear its role in the landscape of XML object models
> (generically speaking). Should I forgo direct use of XOM and opt for
> Nux instead? What tradeoffs does it pose?
>
> Or, more appropriately, where might I find answers to these questions?
>
> By the way, perhaps I should mention that I plan to use eXist for XML
> persistence in the system I'm building.

From a XOM perspective, Nux adds features on top of XOM. Basically,  
I'd recommend to use plain XOM where that's sufficient and pull in  
those add-on features where they seem to have enough value for  
whatever problem you may have at hand.

Below is a figure depicting the architecture in a nutshell.



XOM is a main-memory XML model and can't be made persistent. I think  
the eXist database doesn't know anything about XOM, so for getting  
data in and out of eXist you'll probably wind up not using XOM at  
all, or converting XOM to and from some standard such as SAX, DOM or  
StaX.

Wolfgang.