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 harmonization 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 larger version in PDF file.

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 standardization 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 standardization.

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

  1. thesaurus

    I thought this might help…

    Obstreperous Ob*strep”er*ous, a. [L. obstreperus, from obstrepere to make a noise at; ob (see Ob-) + strepere to make a noise.]
    1. Attended by, or making, a loud and tumultuous noise; clamorous; noisy; vociferous. “The obstreperous city.”
    –Wordsworth. “Obstreperous approbation.” –Addison.
    [1913 Webster]

  2. tz

    Exactly. I’ve said this in the comments section of several articles for months, specifically asking if Office 2007 was OOXML compliant, and if not will it ever be, and if it won’t, why bother?

    The whole point is interoperability (with fidelity, i.e. I don’t hear complaints of Koffice and OpenOffice doing horrid things when opening the other’s ODF). Office 20xx is never going to interoperate, or even be compliant with any “open standard” which comes out of ISO including OOXML.

    But they can play politics – O2K7 sort of does OOXML, and governments sort of require open standards to be used, so they can approve using MSOffice, can’t they? Instead of an internal spreadsheet application server that works with any browser? Or any of the many ODF compliant programs? Politicians often can’t understand the difference between “open and compliant” and slightly open with lots of proprietary, non-compliant stuff that will be almost unavoidable – it will be easier to save to ODF in Word or Excel than to fully standard OOXML.

  3. mike

    it’s obvious that microsoft’s refusal to accept odf as a standard is based on a legacy fantasy of bill gates, namely to make microsoft touch every living person (and get some money from them).

  4. Fred

    You made the common mistake OOXML is “Office Open XML” NOT NOT NOT NOT NOT “Open Office XML”.

    Microsoft wants to muddy the water and have people call it “Open Office XML”. Just like “Windows Genuine Advantage” reshapes the meaning of “Genuine”.

  5. Sam Hiser

    Superb & fresh assessment, Russel.

    Harmonization actually favors the monopolist, too, because it is a time-waster while the market continues to absorb this and other caustic products.

    We need an application-independent format for all document authoring apps. Today, nothing quite resembles that as well as XHTML2 & CSS3.

    It is right and appropriate to stop sacrificing interoperability for innovation. Placing interoperability first is how we got e-mail and how we got the Web. Documents & document authoring tools are equally important.

  6. Sam the Spam

    Excellent points, Russell. Sam, although you are correct in parroting the well known fact that interoperability and standards brought us innovations like e-mail and the web, you are equally incorrect in parroting the false dichotomy between innovation and standards. The Internet, e-mail, the web, and so on are innovations that are the direct result of standards. So drop the BS and realize that even top business leaders know that the success of new technologies (innovation) is closely linked to the development of interoperability standards

  7. Marbux

    tz said:

    The whole point is interoperability (with fidelity, i.e. I don’t hear complaints of Koffice and OpenOffice doing horrid things when opening the other’s ODF).


    It’s not well publicized, but at least OpenOffice does misbehave very badly indeed when it comes to interop. See e.g., this email to the ODF Adoption TC from KOffice KWord lead developer Thomas Zander:

    One thing I have always dreamed to be possible is that when I write a doc in KOffice I can then open it in OOo to use that one feature that’s useful to me and then save it and continue in KOffice without loosing lots of data.

    Its still a dream, of course. Most features are lost on opening and saving it in OOo, but its a nice goal[.]

    The interoperability of ODF implementations is an utter myth. We got tired of banging our heads against the big vendor-controlled ODF TC on the interop issues, which is why we’re now working with W3C Compound Document Formats instead. As Corel’s Product Manager Jason Larock was reported to have said recently:

    However, if there is going to be a document standards battle, CDF will gain a strong following, Larock believes.

    Bottom line: too many people believe the myth of ODF interoperability. Not enough people cared enough to make the myth come true. We think it’s better to use existing XML compound document formats that actually have an interoperability framework and interoperability conformance requirements.

    ODF and OOXML are both hopeless when it comes to interop. Fix it or lose it, folks. It take more than “open” to create interoperability.

  8. Robert E. King

    I remember hearing a quote by Bill Gates that ran something like “I believe in standards; everyone should have their own”. Microsoft is clearly still supporting that viewpoint at the expense of the computing world.

  9. Tracking_truth

    Marbux…why don’t you get some work done with the da Vinci plug? I mean seriously, what expect FUD do you expect to create by visiting blogs and writing the exact same thing over and over again.

    It might be true that ODF has still not finished the work on conformance requirments. (The design choice was obviously done to settle open formula and similar things first so what the conformance requirments demand really is what finally will be used)
    I might also be true that CDF have conformance requirements as the first concern. Yet what you da Vinci guys keep babbling about is pure nonsense.

    CDF require agreement on the profile that will be used for a particular kind of documents and there are not any such profiles for office files. If somebody appear tomorrow with the perfect profile it would allow different office applications that chose to support the profile to interopt perfectly. Forcing microsoft to honor the profile if they don’t really want full interoperability is how hard?

    Even more importantly the perfect profile itself would contain the needed information for writing down conformance requirements for ODF also. CFD does not involve anything that really makes the interoperability of office files more easy.

    On the other hand when ODF has reached the define-conformance-requirements step it will be pretty trivial to use CFD to allow different applications to exchange data in real time in a sharepoint like way. The turth is that the art of how to specify conformance for office like files is needed no matter what format that is used.

  10. JJMacey

    Hi All,

    M$ has to be scrambling. They has so much to loose, but they won’t win in their attempts. The world is tired of shipping plane loads of cash to Redmond.

    Phoenix, Arizona

  11. Pingback: Microsoft abandona ciertas funcionalidades de OOXML | Amephist Braindamage

  12. Tim Richardson

    You end with “the culture of self-interest is not open”. This is often not true. Large open source projects, like GNU/linux, have received crucial support from self-interested parties such as IBM. Open-source is not communism, it is sometimes a valid business model for profit-making firms. For individuals and small firms, contributing to open-source can also be a rational, self-interested choice.

  13. Pingback: When will Microsoft learn (or will it?) « Greg Pyes blog

  14. Pingback: Moved by Freedom - Powered by Standards :: A Blog by Charles-H. Schulz » Blog Archive » Now you see me-now you don’t…

  15. Pingback: Boycott Novell » Russell Ossendryver et al Take on Microsoft’s False Promise of an ‘Open’ XML

  16. Water ionizer


    Thanks for the information,just found this post my technorati news feed section! I was searching for this since past 3 months and i am glad to see it here. Thanking you much


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>