[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?
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! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|