[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Have JDOM / XOM / etc. failed? If so, why?


dom vs xom
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@i...
http://hsivonen.iki.fi/



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.