[jdom-interest] Philosophical XML (was API Inertia)

[philip.nelson at omniresources.com]

> > A document contains a root element and
> > other XML stuff (which isn't important in this discussion).
> 
> Unfortunately that's not true. The other children of a 
> document (or an element)
> are part of XML and part of JDOM. Many people think they 
> should be nodes, but
> some don't. There's still no agreement as to what should be a 
> node and what
> shouldn't.

If we can't agree on how to do detach(), we will never, ever agree on what
should be in a Node base class or interface.  Why?  Because everybody is
right, from their point of view.  There is not one set of requirements that
we can go to to guide us to the correct solution.

What we really need is a way to give node functionality to JDOM using the
concrete classes we have rather than making the concrete classes all nodes.
Combinations of Builder, Decorator and Visitor are all alternate ways to
tackle this problem.  Some sort of base class may be required, but I but
since we will never agree to the specifics of a Node, or more accurately,
there is no Node that will suit everyone, we need to look at another way to
accomplish a node view within JDOM.

from Elliotte....
> Or we can say that XML documents really aren't trees; that they're 
> some strange amalgam of seven different types of things with 
> complicated relationships between the different parts. Of course XML 
> documents are not simply trees, and there are additional constraints 
> like an Element can't contain a Document. However, we can build these 
> constraints on top of a clean tree model using nodes, or we can throw 
> it together as a random hodge-podge of classes. We have no 
> mathematical underpinning to back us up. We have no well-understood 
> data model. And we give up conceptual compatibility with all the 
> other XML specs that do see XML documents as trees (XML InfoSet, 
> XPath, XSLT, XPointer, XInclude, Schemas, TREX, etc.)

I don't think people have come to see JDOM as a random hodge-podge of
classes.  Honestly, a large collection of nodes is a random hodge-podge when
you already know the structure of your document.  It's when you are treating
documents generically as a tree, that the jdom approach falls apart for all
the reasons you eloquently describe.  I just don't want to throw away the
essence of what JDOM is to become a tree of Nodes rather than a Collection
of JDOM objects.

I can teach xml and java newcomers to use JDOM in a day or two.  With a Node
basis, I would first have to review your cs102 data structures texts (nobody
remembers that course IMHO), then teach JDOM and XML concepts.  This is
essentially what happens when trying to teach DOM.