> There's a lessen in there somewhere.

Greetings. I have arrived from the future to spare mankind more years of pain by stating it clear here that the lesson is not "serialize your data to XML".

No? It seems to be working up well enough so far for e.g. ODT, or indeed the web. A file format that might need to be read in 20 years seems like one of the few cases where the super-verbose XML style is actually appropriate.

I'm all for super-verbosity in useful information and flexible structure, but XML is also super-verbose in terms of redundant markup. Compression helps a bit, but it still costs processing power for no real reason. See the good ol' S-expressions vs. XML discussion, recently reincarnated as JSON vs. XML.

JSON is not where one gos to flee verbosity. It is almost identical to XML, save punctuation.

Hm, interesting. Could you explain why the decision to use (zipped) XML in the current MS Office document formats was a mistake? Those document formats are huge hideous beasts, but that's due to backward compatibility with large feature sets, and I don't think that moving off XML would help.

PS: I fixed the typo in "lesson"

The deicision was a big step forward; however, moving off XML to an equivalent but less verbose (in number of meaningless bytes) format wouldn't hurt. All else being equal, it would be less electricity wasted on reading and sending things over the wire, and also more human-readable format. See also: SEXP vs. XML.

This argument applies the more, the bigger markup-to-data ratio is.

The wide availability across numerous platforms of robust libraries and tools for manipulating XML along with its standardization and the ubiquity of its implementation might have played a role in Microsoft's decisions.

its zipped; nothing is wasted.

But to read it you have to first unzip it, and then parse all that fluff.

See also the "wide availability across numerous platforms of robust libraries and tools" to do this, and do it quickly.