[jdom-interest] API Inertia

[Trimmer, Todd]

I definitely agree. One cannot deny XML being tree-based first and foremost.
Extra brownie points for pointing out that other XML specs have adhered to
the tree model and have been proven to work in the field.

When looking at XML generically, a Node that can contain children, yet
happens to not have any, should be treated EXACTLY the same as a Node that
cannot contain children at all. Show me a man who cares that a Node cannot
have children, and I'll show you a man who stopped treating XML generically
5 minutes ago.

Todd Trimmer


-----Original Message-----
From: Elliotte Rusty Harold <elharo at metalab.unc.edu>
Subject: RE: [jdom-interest] API Inertia

At 10:34 AM +0100 5/2/01, Kenworthy, Edward wrote:
>Have to admit, I find this a little confusing. I really don't see why node
>!= Element. Everything else is icing on the Element.

A document is not an element but it's a node.
A comment is not an element but it's a node.
A processing instruction is not an element but it's a node.
A string is not an element but it's a node.

You can argue that attributes aren't nodes. Start tags and end tags 
clearly aren't nodes. But everything else is clearly a node, not just 
a part of an element.

Here's another way of looking at it: We can model an XML document 
very cleanly as a tree. A tree contains nodes and connections between 
them. By doing this we can use depth-first search, breadth-first 
search, inorder, preorder, and post-order traversals, balancing, and 
in general make use of all the wonderful tree algorithms we learned 
about in CS201 Data Structures. It's a straight-forward simple model 
that's familiar to programmers and easy to support and understand.

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

Clearly I prefer the first approach: define a solid tree model fully 
compatible with the XPath/XML Infoset data model, and layer the 
additional constraints on top of that.
--