[From nobody Fri Aug 6 17:05:53 2004 X-Mozilla-Status2: 00000000 Message-ID: <3A8D69C5.DF235A6E@collab.net> Date: Fri, 16 Feb 2001 09:56:21 -0800 From: Jason Hunter <jhunter@collab.net> X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: info@themindelectric.com, webmaster@themindelectric.com CC: brett@jdom.org Subject: how does Electric XML compare against JDOM? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit It has come to my attention that you have a comparison of Electric XML and JDOM, in which there are several misconceptions regarding JDOM. Please allow me this opportunity to clarify. >From http://www.themindelectric.com/products/xml/jdom.html: > As far as we can tell, JDOM was designed to make DOM easier to use. JDOM is a way to represent an XML document for easy and efficient reading, manipulation, and writing. It does not depend on DOM, nor is DOM used under the covers. JDOM is *not* a wrapper for DOM. To put it simply, JDOM is to DOM as RMI is to CORBA. > JDOM uses an existing DOM or SAX parser such as IBM Xerces to create the initial DOM tree Not really. JDOM is an XML document representation. It can be built from many different sources. If you want to build from a file, we recommend you use SAXBuilder which uses a SAX parser and generates a JDOM document in response to the SAX events. If you want to build from an existing DOM tree, you can do that too. We don't recommend anyone build from a file using an intermediary DOM tree; to do so would be inefficient. Other JDOM builders are possible, for example someone contributed a ResultSet builder which builds JDOM from a database query. Any input method is theoretically possible. Similarly, any output method is possible. You can output JDOM as a file, as SAX events, or as a DOM tree. In between you deal with JDOM alone no matter how the doc is built or output. Also, I should point out we can use any XML parser. The mechanism to choose can be either JAXP, or making a specific choice. Xerces is popular, so we provide it by default. > However, this approach limits the performance of JDOM to > the performance of the parser that it uses. There's no way for any XML document representation to load faster than the document parser. But there's no reason JDOM couldn't be integrated into a fast parser. Parser vendors have approached us about parsing directly to JDOM. That's just another builder option. > Electric XML was designed to be a intuitive, small, fast, > standalone parser It looks like you've defined a document representation that's tied to your parser. Is that fair to say? Thus no one can validate if they're using Electric XML? > Namespace operations are much nicer with Electric XML. I'd like to see the justification for that statement. From my perspective, I don't see it. > XPATH integration is seamless with Electric XML. Very nice. If you look in jdom-contrib you'll see the XPath work for JDOM is quite far along. > JDOM performance is limited by the underlying DOM parser. Simple > benchmarks indicate that Electric XML is 3-5 times faster than > JDOM/Xerces. There's no limitation on how fast you can build JDOM. Any builder is possible. Your parser could easily be adapted to output JDOM as fast as it outputs Electric XML. > JDOM is a 50K JAR file that also requires a DOM or SAX parser. > Xerces is 1.4 Meg JAR file. JDOM also requires JDK 1.3 collections, It's JDK 1.2 collections. There's no such think as JDK 1.3 collections. > which are another 250K JAR file if you're using JDK 1.2 or less. JDK 1.1 or less. And, as I've hopefully made clear, Xerces is not at all required. Can I ask, did you truly fit your parser into a 33K JAR? Fully XML 1.0 compliant, except for validation? If so, this is a great opportunity for a JDOM builder. Please do let me know. Hopefully this email helps you understand that JDOM isn't the technology you thought it was. Now that you know about JDOM, I'm curious what true advantages you think Electric XML offers. And I'd like to know if you wouldn't think it better to have Electric XML be one of the smallest and fastest parsers for JDOM and use your experience to help improve JDOM, thus leveraging the position JDOM has already established for your commercial benefit. -jh- ]