OOXML: The Formula for Failure
As I’ve shown, in the rush to write a 6,000 page standard in less than a year, Ecma dropped the ball. OOXML’s spreadsheet formula is worse than missing. It has incorrect formulas that, if implemented according to the standard may cause loss of life, property and capital. This standard is seriously messed up. And shame on all those who praised and continue to praise the OOXML formula specification without actually reading it.
Rob talked about some of the mind-blowing problems with the specifications. It is clear that working on a program without specifications for many years leads to
non-elegant inelegant [Thanks, John] code, workarounds, inconsistencies, inaccuracies, and some ‘features’ that are intended to make different versions of the same software incompatible (to force upgrades and thereby elevate revenues). Writing (or rather “deriving”) specifications from 20 years of coding is no way to write a specification. It’s just a description of a program, with its bugs and deficiencies included.
“OpenXML is designed to represent the existing corpus of documents faithfully, even if that means preserving idiosyncrasies that one might not choose given the luxury of starting from a clean slate. In the ODF design, compatibility with and preservation of existing Office documents were not goals. Each set of goals is valuable; sacrificing either at the expense of the other may not be in the best interest of users.” (p.6 Ecma Response)
As usual, the smart folks from OpenMalaysiaBlog have produced a fairly comprehensive and well-studied article. It demonstrates the serious problems which Rob refers to.
[OOXML:] Mathematically Incorrect
So when it comes to comparing MSOOXML and ODF v1.0 on the basis of the inclusion of “Formula Definitions”, it becomes clear that the anti-ODF folk have not much to shout about. In fact MSOOXML’s “Formula Definition” is deficient and inaccurate.
Can Novell (and particularly de Icaza) still praise OOXML? Can they truly recommend it, invest resources in it, and imply it is the way to go (or at least suggest it’s an acceptable specification)? This whole scenario is worrisome. Is this what Novell got paid over $300,000,000 to do (at least in part)? Whose side are they committed to? The Free software community, which supplied all the software? Or is it Microsoft, which has just betrayed Novell? Perhaps the Jim Allchin comment on “slaughtering Novell” should have served as a clue. Microsoft only embraces in order to weaken and destroy (not only ODF, but also Novell).
This debate about document formats continues. Simon Phipps of Sun Microsystems has published his own bits of advocacy in his professional Web log. He distinguishes between standards that serve companies and standards that serve the customer (that’s where preservation and portability, for example, play a significant role).
There are plenty of examples of a choice of “standards” in our lives (usually validated in some way by a vendor body), but I have yet to find one that actually leads to a benefit to the customer.
Yesterday we talked about some unfortunate news. TurboLinux’s involvement in this ‘scandal’ must now be taken into consideration. I have not read the press release at the time. The press release came from Redmond (not TurboLinux). There were hints there which expose Microsoft’s trick of shoving in proprietary formats through the desktop monopoly. TurboLinux has apparently been paying Microsoft for the right to play media files encoded using proprietary code. Novell was indirectly involved in something similar. This leads to Linux ‘taxation’. OOXML achieves exactly the same thing. That’s why it must be rejected. The world has already got a single, unified document standard.