How difficult is it to understand that half the data exchanged in XML are object graphs and the other half are tables?
How dificult is it to adapt XML to express tables then?
Here is a cheap shot.
<?xml version="2.0" ?>
<member id="1234">
<name>john doe</name>
<phone>555-1234</phone>
<family xsd:type="table">
<row>name |age|address |city |st|zip |phone </row>
<row>john doe | 32|123 nw 45 st|miami|fl|33133|555-1234</row>
<row>jane doe | 30|123 nw 45 st|miami|fl|33133|555-1235</row>
<row>jimmy doe| 12|123 nw 45 st|miami|fl|33133|555-1236</row>
<row>jamie doe| 10|123 nw 45 st|miami|fl|33133|555-1237</row>
</family>
</member>
* For a thousand records you'll see a veeeeery big improvement.
No need for CSV, Excel or EDI files, then and only then XML will be a complete solution. Don't look the other way, accept the cruel reality: data has a squared shape.
Need to transmit only a few positional data?
<weather>8:25am|65F|Boca Raton|FL|33433</weather>
How can you convince an EDI guy that XML isn't that bloated?
<ISA>00||00||30|943274043|01|175315246|990104|1521|U|00401|000000002|1|T|</ISA>
<GS>IN|943274043|175315246|19990104|1521|1|X|004010</GS>
<ST>810|0001</ST>
<BIG>19981231|10429|||||FB</BIG>
Nothing changes, 100% backwards compatible.
The new parsers will understand the tuple structure and xml editors could show a nicely tabulated data grid.
I know you can do better, guys, come on!
If you don't want us to go after binary XML then give us relational XML at least.
Pipes to the rescue!