The Deprecated “Smoke Screen” of MS Office Open XML (OOXML)


BSI British Standards states:

“… a standard is an agreed, repeatable way of doing something. It is a published document that contains a technical specification or other precise criteria designed to be used consistently as a rule, guideline, or definition. Standards help to make life simpler and to increase the reliability and the effectiveness of many goods and services we use. They are intended to be aspirational - a summary of good and best practice rather than general practice. Standards are created by bringing together the experience and expertise of all interested parties such as the producers, sellers, buyers, users and regulators of a particular material, product, process or service.”

In an effort to win quick converts to its bid to have Microsoft Office Open XML (MOOXML) accepted as an ISO standard, Microsoft is deprecating parts of its widely-criticized MOOXML. But whatever the new Microsoft OOXML file format with deprecated parts will eventually look like (if such a format ever appears in an actual application), these cosmetic changes don’t really make a difference for Microsoft or the world. Neither Microsoft Office 2007 or the version after that will ever likely produce a standards-compliant format. Besides, OpenDocument has been around now for a few years and is becoming widely supported in industry. However, there has been no meaningful movement from MS towards support. Actions speak louder than words.

What is described in the ECMA OOXML specification is not what is currently implemented in MS Office 2007. The actual specification: says ECMA OOXML is a format that Microsoft Office 2007 can *read*. Note, however, that it is not the format that Microsoft Office 2007 is actually *writing* for example: The Scripts, macros, passwords, Sharepoint tagshooks, DRM and other tie-ins used by MS Office 2007 are not part of the ECMA OOXML specification. If you try encrypting a document in Office 2007, it is no longer even a zip file + XML at that point. There is no editor reference application for Office Open XML, so an application can send Office Open files to Microsoft Office, and Microsoft Office can open those files, but any edits are saved in a different format!

Launch Microsoft Office and try to save a file in the format specified by the draft standard at ISO. You can’t. There is no compatibility mode in Microsoft Office that limits input to the feature set specified in the official Microsoft Office Open XML draft ISO standard. Any suggestions of interoperability for anyone wanting to support the Microsoft Office Open XML specification is ridiculous, especially since Microsoft itself won’t allow its customers to write to that format.

Microsoft will NOT change its Office program to become compliant with ECMA . The marketing firms on retainer will simply advertise loud and clear that “Microsoft OOXML is now an ISO standard”, and will blur the differences it sees between MS OOXML, ECMA OOXML and ISO OOXML. This will do the trick for most people, who are not technical experts. But they will eventually get caught again in the confusion. Microsoft is not concerned about what the global community needs, but is acting strictly to protect its monopoly.

Deprecating some controversial issues shows some of the signs of the significant failures of the format. Shuffling chapters around and putting some parts in the annex is not the answer to technical shortcomings. Such aggressive proposals at this time, seem more geared to be for “Talking Points” only rather than the sincere interest in creating a truly open standard.

There are still major problems with the format as now proposed in its deprecated form, from cultural and linguistics adaptability problems, accessibility issues, to the reliance on the MS Windows product, the guidance to what is called the “DEVMODE” structure, increased Patent problems, added harmonisation and interoperability problems, such that third party implementation remains almost impossible. And there are many, many other problems with MOOXML as an ISO standard. And let us not forget the proposed format has never been implemented or tested. Indeed, one wonders if MOOXML can be tested or implemented by any vendor other than Microsoft. MOOXML is still far from achieving acceptance as a true standard.

The fact is that even MS Office 2007 itself has not implemented the initially proposed ECMA format. So it is more than apparent that the new “smoke screen” proposals will never be implemented or even if they can be, not even by Microsoft, let alone third party vendors. It also dooms all the .docx files out there already. Is MS ready to carry out a product recall or ready to develop another converter for this problem? Not likely.

Moving stuff into deprecated status does not ease the burden of implementing DIS 29500. The TRUTH IS that every application will need to support the deprecated features in order to read files with the deprecated features.

The legacy binary formats remain closed. If a file is one which was converted from an older format of Microsoft Office by DIS29500 and allowed to wrap the old file in xml, it remains unreadable for everyone else. OOXML is still a closed spec tied into to many proprietary formats.

ECMA 376 is a bomb disguised as a standard. It redefines functions and components just to retain ties to the undocumented legacy formats. Therefore a number of things that should be fixed by now, thanks to better engineering, and existing ISO standards, are left not only unfixed, but even perpetuated by ECMA376. Why? There is a difference between preserving old files and moving them to a new format with all the same internal bugs. In essence, Microsoft is shoving their own mistakes right down the throat of ECMA/ISO. Microsoft has the audacity to appear to be saying that the standard meets a different need, when all it seems to mean is : “we don’t wanna fix our bugs, because that would force us to use standards, and that is unacceptable to us.” Unfortunately, the new proposals illuminate this unchanged and obstreperous position.

Further more the proposed deprecated changes increases the already dramatic overlap with the established ISO standard for Office Documents. If creates new patent problems in such that now MS reserve the right to sue you if you implement any of the deprecated stuff moved to the annex of the proposed standard. It makes harmonization and interoperability worse than ever because without the code for interpreting the deprecated items, any file with deprecated data will be impossible to read properly. It is obvious, but despite the obviousness, the problem persists.

To the extent that Office 2007 will have to be changed, to the extensive coding work which would need to be done, don’t you think it is just wiser to reject OOXML as a ISO standard because it is not one, and for Microsoft to collaborate on the development of ODF and create one universal file format for everyone.

The Culture of Self Interest is not Open

Bill Gates Plainiff’s Exhibit

ABOVE: Comes vs. Microsoft Plaintiff’s Exhibit. See original version here in PDF.

So let us be clear, an ISO standard should benefit everyone and should be developed by consensus for fair competition and through open participation for all to embrace, enhance and share. DIS29500 as now proposed still only serves the commercial interest of one vendor and will always only serve the interest of one vendor - Microsoft. This is the way the OOXML format was designed. It was designed to ferment their monopoly into the sun. Microsoft will make promises to the National Boards that it will fix the OOXML format “later”, but as this standardisation process has shown so far, Microsoft doesn’t keep promises.

Unless wasting time is part of the current marketing tactics used by Microsoft, the most advantageous action would be for that company to accept the standing invitation to collaborate on the development of the established standard, the OpenDocument Format, and to create one universal file format for everyone – the fundamental purpose of standardisation.

This article was originally written by Russell Ossendryver.



Big Blue on OOXML


Some will probably say “it’s about time too”…

IBM has made public an article written by Peter Seebach called “OOXML: What’s the big deal?”.

In it Peter explains in clear and unambiguous language why Microsoft’s OOXML document format (also know as DIS29500 or ECMA-376) is not fit to be an international standard.

Stating what has already been said many times before might be construed as boring or repetitive, but in this case Peter gives a refreshingly concise review and summary of the main issues. Many of which have been lost in the verbosity and plethora of opinion and conjecture that abounds on the web regarding OOXML.

Here are couple of salient comments from the piece:

There have been a number of technical complaints made about OOXML. Every one of them comes down to the same base complaint: Rather than specifying a reasonable common interchange format, OOXML specifies the whole feature set of Microsoft Office, down to bug compatibility. This creates a burden on other implementers which is simply unreasonable (and in fact impossible) to meet, while conveniently being precisely what Microsoft is already shipping. That raises a lot of concerns.

He goes on to examine three categories of “showstopper problems” and gives examples in each. The final category, “Unique Features”, is quite damming in it’s final analysis…

Probably the most famous example is one of the optional settings provided in OOXML. The setting is called “useWord97LineBreakRules”, and it specifies to use the line-break rules that were used in Word ‘97 for East Asian documents. Much like the previous examples, this is of course impossible for anyone else to do, as no specification of these rules is provided. In fact, the OOXML standard even warns implementers not to implement this:

The OOXML standard’s guidance for useWord97LineBreakRules

[Guidance: To faithfully replicate this behavior, applications must imitate the behavior of that application, which involves many possible behaviors and cannot be faithfully placed into narrative for this Office Open XML Standard. If applications wish to match this behavior, they must utilize and duplicate the output of those applications. It is recommended that applications not intentionally replicate this behavior as it was deprecated due to issues with its output, and is maintained only for compatibility with existing documents from that application. end guidance]

This guidance is excellent. Given that there is no specification available of this feature, and it is deprecated, it makes all kinds of sense for people not to implement it. But wait; if it shouldn’t be implemented, why is it in the spec? Compatibility with existing documents is not a reason to add a feature to a standard aimed at interchanging data; users are worried about whether their text can be opened at all in another program, not whether every line break is in the exact same location!

This feature is in the spec because OOXML is not a document interchange format; it’s a careful, bit-for-bit, replication of Microsoft’s historical binary formats, wrapped up in angle brackets.

That’s a cracking analysis. OOXML is NOT a document interchange format. It’s MS Office binary wrapped in XML

Peter’s conclusion says it all.

OOXML is a credible effort to solve a real problem: The problem of how to replace completely opaque binary files encoding ten years of accreted behaviour with partially-legible XML files encoding the same behaviour, down to the last bit. That problem, unfortunately, is not the problem of providing a usable, implementable, exchange format for office documents.

OOXML should not, and must not become an ISO standard. It is, as we have been saying all along, a proprietary vendor’s implementation of their proprietary document format. There will be only one beneficiary if this becomes a global standard, and it isn’t you or me…



Welcome to Mozilla’s new baby: Messaging


Announced yesterday, The Mozilla Foundation has launched a new subsidiary called Mozilla Messaging. It will focus on the Internet Massaging and Communications space.

Here’s a FAQ with some useful information. I was particularly interested to see who is on the board. Marten Mickos (of MySQL) is a pretty “big” name…

This is a very attractive little snippet:

# In some ways we’re re-launching Thunderbird — it’s a project that has huge latent potential, and we’re there to catalyze community driven progress in the Internet communications space. The world of electronic communications is buzzing, with older technologies like email still crucial to our online experience, but complemented by other technologies like instant messaging, social networking, voice over IP, and mobile devices.

I am a user of Thunderbird and the Lightning extension (which will be rolled into TB-3) and am very happy with it’s performance and feature set. Reading the quote above, adding IM and VOIP would really make it a killer desktop app.

Oh yes. I am not one of those who believe everything is going to be “web based” applications either. Call me old fashioned if you want but I still like proper “desktop” applications and local storage. I have a gmail account, but I access it using IMAP and Thunderbird. I rarely use web based email, it just doesn’t “feel right” somehow…

Good luck to Mozilla Messaging. I follow the mailing lists with interest and will help with any input that I can give.


The Open Sourcerer is proudly powered by WordPress and themed by Mukkamu

This site (and most others) look better with Firefox Firefox