[jdom-interest] API Inertia
todd.trimmer at trizetto.com
Wed May 2 13:15:51 PDT 2001
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.
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.
More information about the jdom-interest