I precisely advocate using non-text XML as well. It is not to represent data per se, but to represent it in a human-friendly way. To represent data for a comput

I precisely advocate using non-text XML as well. It is not to represent data per se, but to represent it in a human-friendly way. To represent data for a computer the best way would be to serialize in some reasonable manner a subset of a database: Table { name Schema { ... } Row { enum 123 "text" etc } ... } Table { ... } That is all. Truly, a very good form, suitable for anything, not biased in any way. But it would not be easy for a human to author such a subset without quickly getting lost in tables and records. Yet somehow humans can write gigantic volumes of code. So it is not that it is difficult for us to type or something. What makes writing code easy compared to describing a set of tables? Writing code follows some structure, the grammar. And grammar ends up in an AST, which thus exists there all the time and is the only thing that gets to the computer; text is only the medium. Let’s render AST as XML and see what remains if we drop all text. I see the following: 1) element type and attributes, 2) names and references, 3) an element encloses other elements, 4) elements come one after another. The first two are present in the database form as well, but the last two do not. I think composition and ordering are precisely the tools that let us to implicitly embed some information and make it possible to author large amounts of structured data. (Textless XML by definition has no elements-vs-attributes problem. All goes into attributes except things that have to go into elements. Usually it is not hard to decide: they can repeat, or depend on order, or appear elsewhere; very similar to database normalization.)