We agree that we disagree. "Only one implementation" means JDOM can't be implemented as a wrapper around other models, which means that unless *everything* you're doing is built around JDOM you have to pay the overhead of copying the data out of something else and into JDOM. That imposes storage/CPU overhead, and multiple imports reintroduces most of the same portability risks that multiple DOMs would have.
This simply isn't true. Subclasses of the standard JDOM classes can use different storage models than their superclasses. Parsers can use a JDOMFactory to build instance of the subclasses rather than instances of the standard JDOM classes. This would not necessarily be easy. Then again neither is implementing DOM from scratch.
The point you're making would be a legitimate criticism of XOM. This is one of the points where XOM and JDOM diverge. XOM has many fewer protected methods and fields, many more final classes and methods, and overall much more tightly restricts what subclasses can and cannot change. However, this is simply not an issue that JDOM has. JDOM can be implemented as a wrapper around other models. I don't think anybody's bothered to do this yet because no one has had a big enough need for it, but it's certainly plausible.
--
Elliotte Rusty Harold [EMAIL PROTECTED] Effective XML (Addison-Wesley, 2003) http://www.cafeconleche.org/books/effectivexml http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
