Contribute and be proud of defending Software Freedom from monopolist control! We are intervening in the Apple vs. EC case: Find out more.

FSFE Context Briefing

DIS-29500: Deprecated before use?

[Also available as PDF (1.4M)]

When ECMA submitted MS-OOXML as ECMA-376 to ISO for fast-track approval, several countries1 criticised overlap with the existing ISO standard ISO/IEC 26300:2006, the Open Document Format (ODF).

In its February 2007 response, ECMA admits that MS-OOXML addresses the same high-level goals of representing documents, spreadsheets and presentations as ISO/IEC 26300:2006, but maintains that the standards meet different user requirements. This is clarified by ECMA's statement that the explicit design goal for ECMA-376 is to preserve idiosyncrasies from Microsoft's proprietary legacy file formats. This statement was included in the ECMA response on January 2008 to 113 comments2 made by national bodies during the 2 September 2007 ballot, as well as its 14 January 2008 proposed Disposition of Comments.

Considering that alleged preservation of idiosyncrasies is the stated reason for the entire DIS-29500 ISO process, FSFE considers it worthwhile to investigate this claim in greater depth.

The preservation of idiosyncrasies is a questionable reason for an international standard. The goal of standardisation is to provide consistency and to remove idiosyncrasies, not to perpetuate them. By aiming to preserve idiosyncrasies, the best achievable outcome is good documentation of incompatibilities. When it became clear that the main purpose of DIS-29500 was the documentation of idiosyncrasies, the process should have stopped. That it did not indicates a lack of internal structures in the fast-track procedures to prevent abuse of the international standardisation system.

Analysis of DIS-29500 by the national standardisation bodies quickly revealed that information to preserve proprietary legacy formats was referenced in the specification, but the specification of these formats was missing. So although the preservation of idiosyncrasies was the declared design goal and the reason for the creation of DIS-29500, this information is missing from the 6000+ page specification.

Microsoft recently deprecated its legacy file formats and as part of its response to criticism in the DIS-29500 process announced to finally make documentation of these formats available under the Open Specification Promise just before the BRM. Although there will not be enough time for analysis of comprehensiveness, quality and fidelity of that documentation for purpose of the BRM, it seems likely that Microsoft will declare this a satisfactory response to the question of missing specification in DIS-29500. It would however be premature for national bodies to accept this assertion in blind faith - in particular as publication will take place outside the ISO scope and is subject to all legal concerns regarding the Open Specification Promise.

Simultaneously, ECMA addresses this in Response 34 of its proposed Disposition of Comments by removing all references to idiosyncrasies from the specification and placing them in a newly formed Annex for deprecated information. With the removal of this information from the DIS-29500, the design goal of MS-OOXML can no longer be met. The entire specification has therefore effectively become obsolete.

Analysis has shown before that MS-OOXML is covering the same functional space as ISO/IEC 26300:2006 and is unnecessary. It was ECMA which insisted on backward-oriented documentation of idiosyncrasies being a sufficient motive for ISO to ignore the good practice of forward-oriented standardisation. But even by ECMAs own criteria the rationale for DIS-29500 has been deprecated.

In essence: Response 34 of the proposed Disposition of Comments effectively contradicts and invalidates Response 31, which cites preservation of idiosyncrasies as the primary design goal and reason for DIS-29500. It also invalidates ECMAs February 2007 response to similar criticism.

No implementation of DIS-29500

Because there is no justification for the standardisation of DIS-29500, its approval places an unnecessary cost on competition in the IT sector, resulting in artificially higher prices for end users.

Furthermore, the ongoing standardisation process increasingly modifies what started out as a documentation effort for Microsoft's current default file format. The implementation is already being shipped for some time, and updating the product with the various improvements made to DIS-29500 would result in incompatibility of next year's version of Microsoft Office with the files written by today's version. Microsoft itself maintained this as an argument against these suggested changes during the international review phase.

With more than 2,000 pages of proposed Disposition of Comments and Microsoft as the only party with commercial interest in DIS-29500, it seems likely that we will see significant differences between the DIS-29500 specification and the MS-OOXML implementation, which will nonetheless claim implementation of DIS-29500.

Verification of this claim and ensuring fidelity of written data against the DIS-29500 will be an extremely costly exercise for all users of MS-OOXML. Because there will only be one alleged full implementation available, users will need to carefully compare their binary files against the DIS-29500 specification to protect fidelity of their data.

Microsoft and ECMA are in fact already using this strategy in their current responses to criticism by listing applications that seek compatibility with Microsoft Office 2007 as implementations of DIS-29500. Even where not sub-contracted by Microsoft, these applications certainly use DIS-29500 for guidance on how to implement the current Microsoft file format, but their benchmark for success is not faithful implementation of DIS-29500, it is binary compatibility with Microsoft Office 2007.

It should be noted that a similar situation could never arise with ISO/IEC 26300:2006 (ODF) because it already has several independent implementations. Files written by one application need to be readable by all others, otherwise there is a problem with fidelity in at least one of the applications. Because there is a wide range of applications and users for ODF, such incompatibilities will be detected easily. A diverse user and application base is the best insurance against creeping legacy lock-in.

Remember ECMA-234?

There is no need in the marketplace for ECMA-376, the specification does not deliver the promised preservation of idiosyncrasies, and there is no commitment by Microsoft to implement the outcome of the DIS-29500 process faithfully for a meaningful period of time. Does anyone remember ECMA-234, the "Application Programming Interface for Windows (APIW)"?

This ECMA standard was also put forward as standardisation of the Windows operating system with much the same promises that are being made for ECMA-376 today. It was deprecated just after ECMA-234 was finally standardised when Microsoft published Windows 95, which completely ignored the existence of ECMA-234. Microsoft's product decision made ECMA-234 obsolete and turned the entire specification into a huge waste of collective effort. Without a binding commitment by Microsoft to faithfully implement the outcome of DIS-29500, the current process is promising to go down the same route.

It seems that ISO, its national standardisation bodies and hundreds of standardisation experts around the world are essentially being used for a rather costly product marketing exercise. The question is whether ISO should allow itself to be used in this way.

If it becomes common practice to standardise for promotional effect and then ignore, ISO might find itself deprecated in the area of Information and Communication Technologies.

FSFE would consider this too high a price to pay for approval of DIS-29500.

[1] Australia, Canada, Denmark, France, Germany, Japan, Kenya, New Zealand, Norway, Sweden, Singapore, and the United Kingdom.

[2] BR-0002, CL-0057, CL-0058, CL-0059, CL-0060, CL-0061, CL-0062, CL-0063, CL-0064, CL-0065, CL-0066, CL-0067, CL-0068, CL-0069, CL-0070, CL-0071, CL-0073, CL-0074, CL-0075, CL-0076, CL-0077, CL-0078, CL-0079, CL-0080, CL-0081, CL-0082, CL-0083, CL-0084, CL-0085, CL-0086, CL-0087, CL-0089, CL-0090, CO-0081, CO-0082, DE-0114, DK-0004, DK-0005, GB-0136, GB-0137, GB-0138, GB-0140, GB-0141, GB-0142, GB-0143, GB-0144, GB-0145, GB-0146, GB-0147, GB-0148, GB-0149, GB-0150, GB-0151, GB-0152, GB-0153, GB-0154, GB-0155, GB-0156, GB-0157, GB-0158, GB-0159, GB-0160, GB-0161, GB-0162, GB-0163, GB-0164, GB-0165, GB-0166, GB-0167, GB-0168, GB-0169, GB-0170, GR-0094, GR-0095, IR-0008, IR-0010, IR-0011, NZ-0015, NZ-0016, NZ-0017, NZ-0018, NZ-0019, NZ-0020, NZ-0021, NZ-0022, NZ-0023, NZ-0024, NZ-0025, NZ-0026, NZ-0027, NZ-0028, NZ-0029, NZ-0031, NZ-0032, NZ-0033, NZ-0034, NZ-0035, NZ-0036, NZ-0037, NZ-0038, NZ-0039, NZ-0040, NZ-0041, NZ-0042, NZ-0043, NZ-0044, NZ-0045, NZ-0046, NZ-0047, NZ-0048, US-0096, US-0097, US-0098