Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] DOMConverter getDOMImplementation

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Wolfgang Hoschek <whoschek AT lbl.gov>
  • To: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] DOMConverter getDOMImplementation
  • Date: Mon, 5 Apr 2004 18:41:19 -0700

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





Archive powered by MHonArc 2.6.24.

Top of Page