I have to agree I abused the journalistic bible by using an eye-catching title.
It should have been 'Tabular XML' since it has nothing to do with the relational world but with table-like structures.
First, even if you use elements, attributes or gzip compression, the fact that for every record you will repeat all the properties is a no-no, no matter how you spin it.
For short examples in academia, it looks nice using a couple of attributes, but when you start facing day-to-day challenges like transmitting product catalogs with ten thousand items, thousands of new insurance claims, hundreds of thousands of walmart purchases every day, you start wondering and looking for alternatives.
What options do we have?
- Use another format like CSV, Excel Or EDI for table-like structures?
- Use tags or attributes increasing 10 times the size just to compress it back?
If we want a standard format for exchanging all kinds of messages, we need a format that can handle all kinds of messages, or we will continue hammering it which is not a good sign of a strong standard.
- XML: hierarchical
- CSV: tabular
- EDI: positional
- JPG: binary
- DOC: documents
Second, defining a table in a schema won't be that hard. Every piece of data inside the tuple will be defined with existing xsd:types and they will be referenced by position, they should respect their position, facilitating the life of the next-gen of parsers, producing lightning-fast results. Same as arrays or lists in today's languages. By the way, XSLT can handle that easily too.
Of course it was another mistake trying to use a 'header' to identify the content of the table as first row, it was done just to let the reader understand what the data was all about.
At the end, if I can use XML to send all my messages, regardless of their content, I would be a happier user.
Meantime, let me send this new price list with 20000 records to my partner, in CSV...