RE:JDOM problem

[Joseph Kesselman]

> 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?

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.

If you cut the toes and heel off, maybe the glass slipper will fit, but it still strikes me as a bloody mess. Possible doesn't equal desirable.



As far as ease of teaching:

I'm not sure I understand the "attributes out of synch with namespaces" argument.

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 grant that the fact that the DOM couldn't deprecate the 1.0 non-namespace-aware methods is a significant wart. Sometimes history is a bitch, but at least her puppies are cute.

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.)

... Or are you talking about syntactic versus semantic views of the document? If so, the problem here is that different applications care about different parts of the Infoset, and there's honest disagreement about which portions to display; DOM L3, which finally makes load/save part of the DOM API, partly deals with that by giving us a way to say what details we care about. I fully agree it would be nice if this had been available earlier, but at least this gap is being closed now.

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.



As I say, I think we honestly disagree. Which is fine.

______________________________________
Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL and more.
"The world changed profoundly and unpredictably the day Tim Berners Lee
got bitten by a radioactive spider." -- Rafe Culpin, in r.m.filk