But, of course, this is what the multiple viewing architecture in MVC 
in the 1970s was all about: to allow safe multiple views of complex 
structures.

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

I don't think I'm doing either. I do think that I'm pointing out that 
data structures do not scale at all well, and are quite fragile.

Cheers,

Alan

------

At 3:15 PM +1200 7/20/00, Richard A. O'Keefe wrote:
>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.