Alan Kay <Alan.Kay at disney.com> wrote:
	But all this misses the big point, which is that XML is a data 
	structure that doesn't carry its interpretation around with it (i.e. 
	it is not an object), and thus it falls prey to having many 
	interpreters that have little chance of agreeing on the meanings of 
	data. I hope that any one on this list would and could argue that 
	what needs to be sent around to deal with the problems that XML is 
	supposed to solve is something that is protected, encapsulated, and 
	knows what interpreter must be used to give it meaning -- again: an 
	object.
	
But one of the problems that XML is supposed to solve, and *does* solve,
is allowing *multiple* interpretations of a single data structure.  The
development of SGML was a very conscious stepping *back* from interpretation.

It's perfectly true that many of the things XML is being used for *would*
benefit from being objects instead, but that just tells us that sometimes
XML is used appropriately and sometimes it isn't.

For an example:
    a chemical formula may have an interpretation as text,
    an interpretation as a 3d stick-and-ball diagram,
    an interpretation as a 3d balls-wedged-together diagram,
    an interpretation as a 2d diagram,
    an interpretation as a mention of such and such functional groups,
    an interpretation as speech signals in some human language,
    ...
    your imagination is the limit.
It may need to have more than one of these interpretations at the same
time (say for display and for searching).  And it may have interpretations
in the future that it doesn't have yet.

One of the key ideas behind XML was that XML processors should be able to
handle tags and attributes they've never heard of before, so that an
application can get on with the information it _does_ understand without
hanging forever waiting for an object to connect to a remote site (or
reformat a hard disc...).

If you just take XML as a fairly modest step up from flat ASCII files
(that is accreting a lot of features...) then you'll neither overestimate
nor underestimate XML.