XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

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?


On Apr 5, 2004, at 6:05 PM, Elliotte Rusty Harold wrote:

> > I'm working a lot with converting from/to DOM and XOM, for example via
> > DOMConverter.convert(org.w3c.dom.Document,  
> > org.w3c.dom.DOMImplementation impl).
> > Dealing with JAXP and all its factory layers may be flexible but is  
> > also quite cumbersome to get a default DOMImplementation.
> > XOM users probably would like to avoid digging into JAXP as much as  
> > possible.
> > So here is a proposal to add a method getDOMImplementation() or  
> > perhaps better named getDefaultDOMImplementation() to DOMConverter:
>
> I think that's on the wrong side of 80/20, and I'm not really sure  
> what it has to do with XOM. It's really addressing a hole in DOM, is  
> it not?
> --  
>
>   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