Actually, while XML in readable form is pretty bloated due to it being so verbose (hard to argue with you there). For storage however it can be very compact when done right. This is due to its high compressability, and I do not mean tools like zip and rar, but more specialised compressors. Where a normal compressor needs to build up a model of the data, one with xml/schema knowledge gets a model handed to him, improving the compression.

As for its use in databases as a type, here we don't use the xml type at all and strore it all as text instead. The intersting or frequently accessed bits we work with are extracted by the application and stored in separate fields next to the plain text xml. Storing XML along with the attributes we use does have an advantage to us in three ways:

1. We (and the customer) can quickly see what the source was of the data we work with and check this out when an error is suspected.

2. We can extend the working set of attributes and populate the new ones by extracting them from the xml (with a sql statement if need be).

3. We have the context of the data we use and thus can do some analysis on historical data. Good to have as an option for marketing purposes.

JSON would I think not be suited for any of these points.

As for readability, i love to drag an xml fragment to my browser (IE) and see a nicely readable source, which makes it easy to spot problems, be it programming errors on our side or simply wrong data delivery.

And I agree quite a bit with you Jeff, on the sorry state of current markup languages, especially HTML. In many ways, it feels like old basic with line numbers and no labels or functions all over again. The source of many modern interactive pages is often uncomprehensible by anyone that did not work on the page just a minute ago. That is why developers (me too) are bending themselfs in all kinds of application modeling excersises as we need to get this "mess" under control.