XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

Sorry there were typos in my mail. I ment

"It's a hole in DOM, yes, and should rather <NOT/> be there. But it  
<IS/>, and anyone wanting to use ..."

Anyway, my suggested code snippet gives a reasonable default without  
any further info, right? Or are there DOM libs where the snippet  
breaks, or misbehaves?


On Apr 5, 2004, at 8:00 PM, Elliotte Rusty Harold wrote:

> At 6:41 PM -0700 4/5/04, Wolfgang Hoschek wrote:
> > It's a hole in DOM, yes, and should rather be there. But it isn't,  
> > and anyone wanting to use DOMConverter.convert(org.w3c.dom.Document,  
> > org.w3c.dom.DOMImplementation impl) invariably has to go through it.
> > If convert(XOM --> DOM) is in the API as it currently is, then my  
> > suggestion seems to be on the right side of 80/20...
> > Another way of putting it is: for xom users who (for whatever reason)  
> > have to hand their documents to third-party libs that take DOM input,  
> > do we want to make it straightforward or difficult?
>
> Anyone who wants to use DOM has to go through it. DOMImplementation is  
> not an optional class you can pretend does not exist. If you're using  
> DOM, you need to know how to use this class and how to create an  
> instance of it. More importantly, you have to know which  
> DOMImplementation you're using and how to load that DOMImplementation.  
> Despite the interface based nature of DOM, different implementations  
> are not interoperable and are not interchangeable. XOM does not have  
> enough information to choose the right one for the client.
> --  
>
>   Elliotte Rusty Harold
>   elharo AT metalab.unc.edu
>   Effective XML (Addison-Wesley, 2003)
>   http://www.cafeconleche.org/books/effectivexml
>    
> http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/ 
> cafeaulaitA