With the ECMA dispositions we now have an impressing document that informs us that an ISO OOXML would have to be also backwards compatible to the existing XML office formats of Microsoft that are in early stages of their deployment. The hammering on backwards compatibility reminds you of Henry Ford's colour scheme: People can have the Model T in any colour—so long as it's black. In ISO terms: change ISO DIS 29500 (OOXML) in any aspect as long as we don't need to change.
The "backwards compatibility" has been the most confusing argument for the OOXML format's ISO stamping. To me it sounded first as a silly ad hoc justification. The very purpose of the double standard, Ecma told us, was to preserve the idiosyncracies of the old binary legacy format of a single dominant vendor that is not fully specified but at least sufficiently reverse engineered and supported by other vendors. The "existing corpus of binary documents" was not XML based but it is painless to convert it to the existing international Standard, ISO 26300:2006. The old slack and known bugs reincarnate in a fresh new generation of XML based format: the OOOXML spec family. When does it stop?
The goal is to enable the implementation of the Office Open XML formats by the widest set of tools and platforms, fostering interoperability across office productivity applications and line-of-business systems, as well as to support and strengthen document archival and preservation, all in a way that is fully compatible with the large existing investments in Microsoft Office documents.
or in the ECMA fast-track response very explicit:
First, while both formats share the high-level goal, to represent documents, presentations, and spreadsheets in XML, their low-level goals differ fundamentally. 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.
The recent ECMA comments disposition expand the notion of "backwards compatibility" to proprietary earlier versions of the open XML format. And ECMA also stresses (704):
Documenting the Microsoft Office “binary” file formats (i.e., .doc, .xls, and .ppt) (the “Binary Formats”) is not the intention or in the scope of DIS 29500.
Therefore the so called "backward compatibility" claim cannot be verified by a third party. No one can verify the claim of backwards compatibility as these binary formats are semi-documented black boxes.
The IE tells us a lesson. Internet Explorer Platform architect Chris Wilson explains the backwards compatibility trap of another application:
… developers of many sites had worked around many of the shortcomings or outright errors in IE6, and now expected IE7 to work just like IE6. Web developers expected us, for example, to maintain our model for how content overflows its box, even in “standards mode,” even though it didn’t follow the specification – because they’d already made their content work with our model. In many cases, these sites would have worked better if they had served IE7 the same content and stylesheets they were serving when visited with a non-IE browser, but they had “fixed their content” for IE. Sites didn’t work, and users experienced problems.
Contrary to popular slander the problem of standard non-conformance is not IE specific and applied to the Netscape browser as well. A sluggish design or neglection of standards would cause problems in later stages of the process. But it is not that easy. You need to keep in mind that a standardization organization is not always the right place to discuss improvements as it keeps a certain conservatism about the objectives of the format. The question: How can you please your application customers and satisfy different format religions of document-driven standard fathers? It is also admitted that standardization bugs as Y2k with slavish implementations may cost billions. A lesson is that what really matters is the openness of your standard implementation process. Implementation bugs became a profitable business for web agencies for which the ingrates cursed browser providers. In the early 90th Microsoft faced a lot of public criticism over its web standard implementation practice that was safely ignored by the company. A significant number of signatories of the Noooxml.org petition still express their past dissatisfaction with IE implementations. A primary business reason for these moves of Microsoft was of course the fast development and competition between the products and a slow standardization process. Now that the romantic phase is over janitors have a hard time. Chris continues:
With this painful and unexpected lesson under our belt, we worked together with The Web Standards Project (in the WaSP-Microsoft Task Force) on this problem. I can’t give them enough credit for this work; it’s tough to step into the shoes of a browser vendor that ships to half a billion users to figure out what the best thing to do is, when you really just want to sit down and write code to the standards. We started from a simple statement of “enable (and encourage) interoperable web development, but don’t force IE to break pages that work properly in IE today.” I think we all want to converge to a world where a web developer doesn’t have to spend much time at all testing and recoding their site for different browsers. At the same time, we can’t break the web experience on current sites for users like my mom, even for as good a reason as improving standards compliance.
What does it mean for Office Open XML? No one can make sure that there will ever be an implementation of OOXML that conforms to the DIS 29500 specification. When changes are made to the specification there is still no guarantee that they would be applied in actual implementations. This is especially of concern for a government user that would decide to adopt a technically fully fixed ISO standard.
What is the solution?
- First of all, adopt a well designed and documented format that provides a clean start. Migrate to a clean and compliant generation if you cannot fix the old. XML migration was a missed opportunity for Microsoft in that respect.
- Risk to break a format's backwards compatibility in early stages of the format lifecircle. Early Refactoring
- Step up to ensure compliance of your implementation with a specification as soon as possible.
- enable early peer review of your well-documented developments, esp. document and justify deviation from existing international standards