[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: JDOM vs. JAXP/Xerces for XML document creation
On Tue, 2002-07-16 at 09:02, Elliotte Rusty Harold wrote: > >- There is one and only one JDOM. If you commit to it, > >you have the source code and and open process to work with, > >but no alternatives to easily switch to. > > Please remember that you absolutely can switch parsers. JDOM supports > just about any SAX2 parser on the planet. You can even use a DOM > parser if you really want to. In practice JDOM code is *much* more > portable across parsers than DOM implementations are. I have yet to > be able to run a significant DOM program on two different DOM > implementations (in Java) without debugging and rewriting some code, > even in those parts that are allegedly standard. Was it due to differences in interpretation of the specifications, bugs in the implementations, or differences between your interpretation and the implementation interpretation? From my experience, switching from one implementation to an other helped discovering bugs in my own application as well as in implementations. JDOM has the advantage that there is no specification since it is only one implementation. Someone using only one implementation of the DOM would run into less troubles. Doing cross-platform, cross-JVM, and cross-implementation Java application is harder, no doubt about it. > >- JDOM's architecture expolits the fact that there it doesn't > >have to worry about multiple implementations. This is a strength if > >you like to use classes and constructors rather than > >interfaces and factories, but some prefer the design patterns > >that these facilitate. > > Be that as it may, I'm coming to realize that an interface-based > solution is fundamentally wrong for XML read-write APIs. DOM has some > very deep flaws at its core precisely because it is based on > interfaces rather than classes. For a long time, this was hidden from > me by the sheer ugliness of DOM stemming from its IDL heritage. But > DOM has deeper problems than that. As Mike suggested, this seems to be more an design pattern problem than a XML/DOM specific ones. Why interfaces would be a bad thing for DOM and not SAX for example? It is true that extending the DOM requires to be implementation specific - most of the DOM implementations are using internal attributes/methods when manipulating the DOM nodes - but still being able to manipulate the extension as a transparent DOM Node is useful. > Come to the New York XML User's Group meeting September 17 if you want > to hear me explain exactly what is wrong with DOM (and JDOM, and > ElectricXML, and dom4j) and how it can be fixed. The DOM WG is always willing to listen if you want to share your ideas regarding XML APIs. We recently stopped working on Abstract Schemas after feedback, some (most?) of them came from this mailing list in fact. Stopping a draft after 2 years of work is not an easy decision but is still possible. However, I do believe than restarting from scratch the DOM API with the same set of requirements would produce the same result, and only a reduction of those requirements would help simplifying the DOM API. Parts of the complexity of the DOM API is the complexity of XML itself and the read/write aspects. > I also plan to release what I suspect will be the first genuinely > correct tree-based API for XML processing in Java. I don't think that anyone can pretend to have _The XML API for processing XML_ whether it is DOM, JDOM, ElectricXML, or dom4j. DOM is probably the API which the largest number of requirements and that does not always play in its favor. SAX1 is (and will continue to be) probably the most successful API for XML. However, in order to share ideas and opinions, I might be able to stop by NYC if necessary, it is not so far from Cambridge (MA) anyway. Philippe
|
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
|