Lists Home |
Date Index |
Alaric B Snell wrote:
> Since elements must be nested, and each element either has no parent elements
> (the root element) or has precisely one immediate parent then a path of parents
> up to the root, the elements form a tree.
> That doesn't mean you have to think of them as a tree all the time; SAX
> doesn't. But they're still a tree.
We're talking past each other. It's not the first time. I'll consider it a
symptom of the failure of my expository skills.
Your first paragraph above is polemic and, again I'm afraid, grounded in petitio
principii. As the composer of an XML instance you intend a tree (which is
perfectly your right). The WFCs, read in the light of that intent, support your
argument for what constitutes a tree. QED, apparently. In the second paragraph
you see another possibility; you even cite a familiar and common example.
However, for your conclusion you revert to the premise/conclusion of the first
paragraph. I understand perfectly what you want to say and in fact I sympathize
with it. However, I am taking the time to analyze it in this way because the
argument you make above is in fact the clone of the manner in which you expect to
process XML. Intending a tree, you expect to see your instance processed as one.
In tightly coupled interaction between a document creator and consumers who share
a good deal of agreement outside the XML instance at hand, that is reasonable
enough. It is not however the general case for the understanding and processing
of XML instances qua XML instances, and never will be no matter how much you
insist that it's still a tree.
Again, to quote Gavin's masterful aphorism:
***The generic XML processor is a myth once you get past the syntax.***