In my opinion, the new formats are little more than XMLified representations of implementation details of how MS Office works; there is a distinct proliferation of elements that aren't purely semantic, and an awkward-but-inconsistent lack of separation of structure from presentation. But I'm not an expert on the binary formats nor the inner workings of their applications. Though my opinions remain unchanged after 9 years, in retrospect I do like that the new formats are documented by a true standards body, and are interoperable not just by reverse-engineering a closed format.

[1] http://noooxml.wikidot.com/start

https://blogs.technet.microsoft.com/markrussinovich/2006/01/...

Is ECMA that "true", I don't know. At least they document a JavaScript without "JavaScript" in its name. MS Office (2010 at least) isn't compatible with the standard text. Is there even a MS Office nowadays that's better? Also Office 2010, dispite support, is hostile to OpenDocument format - opening a document gives you warnings about legacy format and what not.

The OOXML standatisation process was very controversial and left a bad taste around MS and ECMA Switzerland: https://en.wikipedia.org/wiki/Standardization_of_Office_Open...

But in practice there's no such thing as "OOXML" - there's only what Office 2007, 2008, 2010, 2011, 2013 and 2016 happen to do. So if you want to work with the stuff, you verify everything. The standard is, like so much Microsoft documentation, best treated as based-on-a-true-story fiction with an unreliable narrator.

http://phpexcel.codeplex.com/discussions/71551

For the most part, with Word I get better compatibility in LO with the old binary formats than with OOXML. If someone sends me .docx and it looks garbled, it's easier to ask them to resave as .doc than to try to get them to produce .odt

It is literally a zip file containing a some xml files [0]. Having said that, the spec is still 106 pages, but the entire xml schema is only 8 pages; the rest is exposistion.

[0] Some features (such as embedding images) probably involve including non-xml files.

[1] https://msdn.microsoft.com/en-us/library/dd773189(v=office.1...

http://activityworkshop.net/rants/ooxml.html

https://en.wikipedia.org/wiki/Comparison_of_Office_Open_XML_...

https://en.wikipedia.org/wiki/Standardization_of_Office_Open...

More fun: you know what happens if you save a .DOC in Office 2007/2010/2013? Any features past 2003 are saved as a lump of OOXML! http://vmiklos.hu/blog/doctok.html#comment-header

You know the author was part of Excel team, don't you?

The article seems like an explanation, not a justification. Moreover, I totally agree with the conclusion: use OLE to extract information programatically.

But the format is still terrible :-) The fact that there were reasons to do it that way at the time is not the same as saying the decisions were the right ones. Probably there were reasons to do <insert here any despicable historical or technical catastrophe>.

I'd say that they were the right thing to do at the time, but in the long-term they turned out to be less than ideal.

From Microsoft's perspective, the formats allowed them to be faster than the alternatives, seemed easy to maintain internally from the sound of it, and they were able to cut and run from the format when needed.

If they decided to go with a format that would be "good" for the next 30 years, would they have been as competitive back then?

One thing overlooked is that the transition to the new DOCX formats (and PPTX, XSLX, etc.) was that they were being written about the same time Windows was working on Longhorn. Longhorn featured WinFS. WinFS would open the XML document formats and save assets like embedded images as their own components in the filesystem and then would reassemble the documents as you moved them from a WinFS store back to a traditional filesystem. The XML formats were in a similar way designed to make that process fast, just as the binary images did for earlier versions of Windows. The XML document formats were designed to integrate with a filesystem which never shipped. Without WinFS, the formats weren't built for third party interoperability, but were designed to make it easy to decompose a document into block components which the Office apps otherwise handled like verbose but compressed binary formats. If WinFS had shipped, the OOXML formats might not seem as convoluted.

Other definitions of "right" could reasonably include "our software performed the intended functions expected by the people that paid for it."

One common definition of "right" in capitalist countries is the fiduciary responsibility to maximize profit. It's not one that I personally think works in every scenario. That version of "right" can often find it's self in direct contradiction of definitions from moral, social, and legal areas.

My only point was that "right" means a very particular thing on HN. It means Unix-y...but not actually Unix...its this Unix that inhabits someone's mind. Where X and sockets are also "files" and text is the only RPC system you would ever need. It's also functional programming fetishistic. LISP because of the great PG. Erlang because I heard of this one really awesome app with great up time...and have you heard about Plan 9, it's perfect if it weren't for {insert dark force of mediocracy} that kept it from being a winner.

Thanks for asking. I've been needing to say that to someone for a long time.

If anything, I'd say they're worse.

https://en.wikipedia.org/wiki/Office_Open_XML

XML'ized everything (yuck!), and instead of "just" Microsoft having control over the format, it's now a whole design-by-committee bureaucratically bloated mess with other parties trying to stuff things in too.

It is far easier to repair and recover an xml file than a binary format.