This simply isn't true. Subclasses of the standard JDOM classes can use different storage models than their superclasses. [...] JDOM can be implemented as a wrapper around other models.
How do you do that without having the subclass carry all the (unused) fields from the superclass's storage, with attendant waste of bytes?
You might have a few extra null fields in some objects. It's not a huge problem.
Also, I've found that this sort of model-replacement subclassing is somewhat fragile. Developers frequently forget to subclass everything, with the result that some method references the old model's field. In that sense, it *can* be more difficult than implementing an interface from scratch.
Yes, if the developers don't write the code correctly it will have bugs. Still I find these bugs easier to test for and recognize than bugs created by failure to follow unenforceable rules in the DOM spec.
As far as ease of teaching:
I'm not sure I understand the "attributes out of synch with namespaces" argument.
There are two sensible models fro handling namespaces. You can either represent them as attributes or you can make them properties of the elements with the various prefixes. Doing both at the same time with no requirement for them to be in sync in any way is insane.
Nodes being moved across documents becomes Significantly harder when more than one implementation is running around. JDOM has avoided that by not having multiple implementations, but your reimplement-by-subclassing would reintroduce it and I think you'd wind up with the same importNode/adoptNode solutions the DOM has to deal with those cases.
I don't see how. JDOM classes do not depend that deeply on each other as a typical DOM implementation does. Making the DOM actually work behind the scenes normally requires using implementation-specific non-DOM methods. That's not true of JDOM. Everything can be and is handled through the public API. You can freely mix and match node classes from different subclass hierarchies.
JDOM avoids confusion of physical/logical, again, only because it has only a single implementation. Your reimplement-by-subclassing breaks that behavior too. (Though in fact, the point of an API is that you shouldn't _need_ to know physical storage details; just use the API and it all works.)
That's not what I meant. Sorry. I should have been more explicit. The issue is entities. They are part of the physical model, not the logical model. And yet DOM exposes them as part of the logical model. I can have two DOM elements, both of which have the logical content <test><data/></test> and in one of them the data element is a child of the test element and in one of them it isn't, because in the second it was loaded from a parsed entity. Annotating nodes with the entity they came from as SAX does may occasionally be helpful. There's no reason to make this part of the tree structure though.
Disjoint types is not always an advantage, eg when writing a thin API layer on top of another back-end model. And the only place it's a particularly large advantage is if you're using it to drive overloaded-method selections; if you're just talking about instanceOf, getNodeType is just about as convenient. I can see cases where this is an advantage, but not a huge one.
getNodeType() works and is often even faster than instanceof. Nonetheless, the fact that instanceof is broken with DOM is a problem. This is a core part of Java, and it just doesn't work reliably with DOM.
I'd also claim that joined types is OOP impure. An Attribute is not an Element. A comment is not a processing instruction. They should not be implemented with the same class. This is a complete violation of the whole notion of type-based programming. It might make sense in a dynamically typed language such as Python or a weakly typed language such as C. But it's clearly wrong on first principles for strongly, statically typed languages such as Java, C++, and Eiffel.
--
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]
