[
Lists Home |
Date Index |
Thread Index
]
On Mar 30, 2006, at 21:36, Michael Champion wrote:
> I got a very interesting bit of devil's advocacy that went
> something like this: "People complain about the DOM, but they
> don't embrace alternatives. For all the work that people have done
> to provide alternatives such as JDOM, dom4j, XOM, etc. in the Java
> world, the typical users and the major Java players still use DOM,
> warts and all." I'm not at all convinced this is true, but I
> don't have any information at my fingertips to dispute it. Would
> anyone care to present facts on one side or the other?
I don't have any facts other than what affected my own decision.
(Expanded from http://hsivonen.iki.fi/cms/te/#h52 )
Why not Electric XML:
Not Open Source. Open Source alternatives exist.
Why not JDOM:
The main selling point was using the Java Collections API, but I
wasn't interested in that. I was interested in fast nextSibling and
firstChild. (I checked the source of a couple of DOM implementations
to see that the time complexity of these operations is sane.)
Moreover, one of the big bugs of the DOM is that CDATA nodes exist.
JDOM also has CDATA nodes and I thought it was a big sign of still
not getting it right. (JDOM also has DocType nodes.)
Why not dom4j:
Elliotte Rusty Harold described dom4j as a more complex fork of JDOM
( http://www.cafeconleche.org/XOM/whatswrong/text15.html ). Poking
around in javadocs confirmed the feeling of complexity and still not
getting it right.
Why not XOM:
It really boiled down to DOM vs. XOM. By looking at the API, XOM
appeared to be the better API. Also, it appeared that John Cowan
liked it it, which was a good sign. However, DOM was poison I already
knew from JavaScript. I already knew what the problems of the DOM
were and how to route around them.
Also, in 2003 DOM was used widely enough for me to believe that at
least one of GNU JAXP, Xerces and Crimson would actually work. Had
XOM turned out to be broken, there would have been no escape besides
fixing it myself. (Crimson turned out to have some getElementById
issues, which is why we couldn't use it throughout the project. GNU
JAXP had a fatal NullPointerException crasher, and I was unable to
figure out how the null got there. In the end, we indeed had to
switch implementations to Xerces.)
So the choice I had was between a better API and a known poison with
multiple implementations and network effects. One of the reasons that
tipped the balance in favor of the DOM was that XOM was under LGPL.
At the time there had been anti-LGPL FUD saying that the Apache
Software Foundation won't use LGPL, because the contagiousness of
LGPL is not understood when applied to software that does not have C-
style linkage. The FUD has since been toned down, and I have used
Hibernate. Anyway, I think it is a strategic mistake for the underdog
to choose LGPL when the incumbent is under an Apache license. If you
want to compete with an Apache project (Xerces DOM), shouldn't you
choose an even more permissive *and* GPL-compatible license like the
MIT/expat license?
I am a bit ashamed of my choice, but because of both technical and
legal certainty, I chose DOM. Since then, I have had code written
against the DOM API, which makes switching to another API a
relatively larger effort...
> - Duh, the network effect. A mediocre standard beats a better non-
> standard every time.
Yes.
> - Serious XML developers use XSLT for the heavy lifting and simply
> don't worry about APIs any more.
I like SAX pipelines, but perhaps it is just me.
--
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
|
