This article refers back to another article highlighting the awful ODF support in Microsoft Office 2007.2 (aka 2007 SP2). which also quotes an article by Rob Weir. Even for Microsoft, this is pretty damned egregious:
The new entry to the mix is Microsoft Office 2007 SP2, which has added integrated ODF support. Unfortunately this support did not fare well in my tests. The problem appears to be how it treats spreadsheet formulas in ODF documents. When reading an ODF document, Excel SP2 silently strips out formulas. What is left is the last value that cell had, when previously saved.
Sheesh. I write only a minimal amount of software, but I do enough testing to catch First Class Foul-Ups like this. Continuing on:
This can cause subtle and not so subtle errors and data loss. […] In general, SP2 converts an ODF spreadsheet into a mere “table of numbers” and any calculation logic is lost.
In the other direction, when writing out spreadsheets in ODF format, Excel 2007 SP2 does include spreadsheet formulas but places them into an Excel namespace. This namespace is not what OpenOffice and other ODF applications use. It is not the ODF 1.2 namespace. It isn’t even the OOXML namespace. I have no idea what it is or what it means. Not every ODF application checks the namespace of formulas when loading documents, but the ones that do reject the SP2 documents altogether. And the ones that do not check the namespace try and fail to load a formula since it is syntactically different than what they expected. The applications essentially display a corrupted document that is shows neither the formula nor the value correctly.
In other words, instead of doing what the standard says, Microsoft makes up their own completely different thing and expects the rest of the world to play along and “fix” previously working (standards-compliant) software to interoperate.
Note to Microsoft: This is not how standards work. Frankly, if you don’t intend to support ODF properly, you may as well not support it at all. What your product writes isn’t ODF. When your product reads ODF, it silently discards important parts of the data. (Yes, the formulas in spreadsheets are important. That’s the whole purpose of a spreadsheet program! Otherwise we may as well be using pencil, paper, and calculators.)
The Groklaw article goes on to highlight the failure of Microsoft to properly implement password protection. I personally tend not to use format-specific encryption features in favor of more general solutions such as OpenPGP-compliant encryption, but this is important nonetheless, as (quoting Jomar Silva, as quoted in Groklaw):
I would really like to find a good technical explanation for this, since the encryption and password protection are fully specified in ODF 1.0/1.1 (item 17.3 of the specification), and they are using existing algorithms, very familiar to any developer.
The grizzled veterans of computing will remember Microsoft mucking up MS-DOS to not run Lotus 1-2-3 properly, crippling Windows 3.1 to crash under DR-DOS, and other similar sins. More recently Microsoft states in their end-user license agreement (EULA) for Office that the user is only licensed to run Office under a genuine copy of Microsoft Windows. That is, if you are running Office under Wine, ReactOS, or any similar Windows-compatible replacement code, you are in violation of the license agreement.
The Groklaw article goes on to reveal part of a Microsoft internal memo discovered during antitrust litigation:
Our mission is to establish Microsoft’s platforms as the de facto standards throughout the computer industry…. Working behind the scenes to orchestrate “independent” praise of our technology, and damnation of the enemy’s, is a key evangelism function during the Slog. “Independent” analyst’s report should be issued, praising your technology and damning the competitors (or ignoring them). “Independent” consultants should write columns and articles, give conference presentations and moderate stacked panels, all on our behalf (and setting them up as experts in the new technology, available for just $200/hour). “Independent” academic sources should be cultivated and quoted (and research money granted). “Independent” courseware providers should start profiting from their early involvement in our technology. Every possible source of leverage should be sought and turned to our advantage.
I have mentioned before the “stacked panel”. Panel discussions naturally favor alliances of relatively weak partners[…]. Thus we find ourselves outnumbered in almost every “naturally occurring” panel debate.
The key to stacking a panel is being able to choose the moderator. Most conference organizers allow the moderator to select [the] panel, so if you can pick the moderator, you win. […]you have to get the moderator to agree to having only “independent ISVs” on the panel. No one from Microsoft or any other formal backer of the competing technologies would be allowed -just ISVs who have to use this stuff in the “real world.” Sounds marvellously independent doesn’t it? In feet, it allows us to stack the panel with ISVs that back our cause. Thus, the “independent” panel ends up telling the audience that our technology beats the others hands down. Get the press to cover this panel, and you’ve got a major win on your hands.
This is the kind of marketing and publicity that gets people to say things like “damn marketers” and much nastier things I won’t repeat here. In short, this is Fraud. Yes, with a capital F.
My response to the author of this memo: If you find yourselves outnumbered because nobody backs your proprietary standard, doesn’t that alone tell you something? Nobody wants to be locked into what Microsoft says, at Microsoft’s prices, upgrading when Microsoft says it’s time. The rest of the world has spoken: they want their freedom. That’s why we have ODF, HTML, CSS, JPEG, PNG, Ogg, Vorbis, FLAC, Theora, Speex, the GNU operating system (commonly deployed as the GNU/Linux variant), and OpenBSD.
Were an individual software author to try this type of shenanigans, that author would be branded a sociopath, and rightfully so. Wake up and listen to the masses, Microsoft. Interoperability doesn’t mean “write it so only Microsoft products can read it.”