20 good reasons to disapprove OOXML

We recommend all national bodies to disapprove the proposed ISO/IEC Draft International Standard 29500: Office OpenXML (OOXML) as amended by the Ballot Resolution Meeting (BRM). This document will summarise the technical reasons why OOXML is not suitable as an ISO standard at this stage.

By voting disapproval you acknowledge the failure of the fast track process to produce a technically mature text, a text that meets ISO quality standards.

Disapproval does not mean a final rejection of OOXML:

  • Vendors are still free to implement the ECMA International Standard version of OOXML: ECMA-376
  • ECMA-376 is expected to adopt all the improvements from the ISO DIS 29500 process, taking into consideration the 3500+ comments from national bodies, the 1200+ ECMA proposed dispositions of these comments and the 40+ items the BRM debated. Additionally ECMA has sufficient time to fix the unresolved issues.
  • Microsoft / ECMA is encouraged to submit OOXML as a New Work Item Proposal in the normal track process of ISO. However, its limited scope "to represent faithfully the existing corpus of word-processing documents, spreadsheets and presentations that have been produced by Microsoft Office 97 to Microsoft Office 2008 applications" is best formalised as a "Type 2 Technical Report" or "ISO Agreement", which carries the the ISO weight for a single vendor and product line specification.

We recommend National Standard Committees worldwide to disapprove OOXML

  1. ISO's "Fast Track" process was abused for standard development 'on the fly'. In the past ECMA has "fast tracked" small (50-500 page), mature and industry accepted standards. OOXML is large (6000+ pages) and immature. An editorial of Redmond Developer News described: "By contrast [to ISO 26300], the Microsoft OOXML specification takes what might be called a kitchen sink approach." — an ISO process is not thought to become a kitchen sink for half-baked ECMA standards. OOXML was only released in 2006 and is hardly accepted by the industry. The OOXML community around the format is a community of one. All third party supporters have contractual relations with the vendor. The limitations of the "Fast Track" process; fast evaluation time frames, extremely limited time to resolve all the concerns and little room for modification has demonstrated that the "Fast Track" process was unsuitable for OOXML. It gives us little surprise as the process was never intended for standard development.
  2. OOXML is a proposed parallel standard without a justification. No empirical evidence was provided for the assertion that OOXML faithfully represents the corpus of existing documents of a specific vendor as opposed to the existing ISO standard or customized versions thereof. ECMA's branding of the format as a silver bullet for archiving cannot be tested by NBs. Additionally ECMA failed to provide a mapping between the legacy binary formats and OOXML. The binary legacy specifications was only made public in 2008. Multiple standards for the very same purpose with conversion issues undermine the respect for ISO standardization. You need a consistent justification to adopt another ISO standard for the same field which is not build upon an existing ISO standard - not to mention backwards compatibility to ISO 26300 architecture.
  3. OOXML's ISO agenda is to undermine the adoption of the existing ISO Office standard. OOXML evangelist Mahugh explained: "When ODF was made an ISO standard, Microsoft had to react quickly as certain governments have procurement policies which prefer ISO standards. … Microsoft therefore had to rush this standard through. Its a simple matter of commercial interests!" A disapproval would motivate the submitter to contribute to the existing ISO Office format, ODF (ISO 26300). We find historical precedence for a proposed Microsoft standard being disapproved in order to constructively motivate harmonization of standards: the Microsoft VML and W3C SVG standards. Microsoft's VML was rejected at the W3C in favour in Adobe's SVG. Microsoft's response was to join the W3C working group to improve SVG which later became a W3C standard. To the extent that SVG is incorporated into ISO/IEC:26300 SVG is an official ISO/IEC/ITTF international standard.
  4. OOXML is incompatible with ISO/IEC and WTO Technical Barrier to Trade (TBT) basic principles, which ISO/IEC are supposed to respect. The BRM added the notion of "Microsoft Office 97 to Microsoft Office 2008 inclusive" to which products' formats a 'faithful representation' is sought by the proposed ISO standard. International standards are not permitted to discriminate specific vendors positively, and thus all competitors negatively. The standard would become a technical market barrier, a tool of unfair competition. Formally a standard is supposed to avoid referencing products. Non-compliance with WTO requirements on technical barriers to trade due to formalities will be an obstacle for the adoption of OOXML in the public sector and undermine trust in the ISO label.
  5. The BRM heavily amended those ECMA 'dispositions of comments' it had time to discuss. The BRM only discussed about 10% of the known technical issues. Of 54 non-editorial issues covered in detail, 48 were modified at the BRM. This left 850 issues without check-over, and pushed through by a bulk vote. These 850 issues were not discussed by the BRM, not modified, and so we can assume that 90% of ECMA dispositions are immature. You can have a look at the approved ECMA dispositions and you will find:
  6. Bulk approved ECMA dispositions are poor in quality and do not address the technical issues sufficiently. For example, GB-0634 raises concerns on the non-descriptive and inconsistent names ("t", "mid" or "b"). ECMA responds by defining new names ("top", "center, "bottom") additionally. The UK delegation voted against this proposal, but due to the "approve" voting bloc, it was 'approved' by the BRM. This is one example of bad dispositions being voted through due to the time contraints at the BRM.
  7. There are contradiction in the dispositions which were 'approved' by the NBs in the BRM. A common example: both Response 222 and 691 were "Accepted" in the paper voting in the BRM, and they contradict each other in terms of the editing instructions and the concept of whether XML schema contained in the text or in the electronic annex have primacy. This particular example is further confused, as the entire schema is being copied into the document as part of the restructuring of the draft standard into a multiple part standard. In other words, there are now at least 3 copies of the schemas, with some question as to which is the definitive copy. It is unknown how the editor will resolve contradictory binding BRM resolutions. He is supposed to deliver the final text.
  8. There will be no Finalized Text for National Bodies to vote on. The results of the BRM only emits editorial changes. The National Bodies' final decision will be based on the BRM editors instructions (which contains complex and big structural changes), 2300 page ECMA proposed disposition (which may or may not have been approved by the paper vote) and the original 6000 page document. National Bodies are expected to 'approve' a large body of text which is unconsolidated. This is irresponsible.
  9. The text is not compliant with the "Rules for the structure and drafting of International Standards" (ISO/IEC Directives, Part 2, 5th edition). The text is an heterogeneous construct, and it disregards the ISO/IEC basic quality and consistency principles. Naming conventions are not defined, the same element names have multiple definitions withing the spec ('e' has 18 definitions) and the same feature has multiple names across the different parts ('jc'/'alignment'/'pPr' all mean 'text alignment').
  10. OOXML reinvents the wheel, it suffers from a syndrome also known as 'not invented here'. Throughout the spec, OOXML goes on to ignore industry accepted, vendor neutral and mature standards like SVG, MathML, XForms and even XML. The most prominent example is the neglection of MathML where OOXML defines its own formula markup language (OOMML). The argument provided by Microsoft on why MathML was avoided was because MathML cannot be extended to cater for change tracking. But XML is defined as eXtensible.
  11. OOXML has patent issues. the BRM has adopted, contrary to the requests of some National Bodies, to recommend patented and royalty bearing audio (MP3) and video (MPEG2) formats for producers [and consumers] that want interoperability. Even though the word should is used it is, in practice, a must since the purpose of a standard is interoperability.
  12. OOXML still requires undisclosed copyrighted material from Microsoft Office. The previous problem of Border Style art being undisclosed was acknowledged and fixed on February 22nd 2008 however Part 4 2.18.94 ST_TextEffect (Animated Text Effects) describes VML art that is not included in the specification. The end result is identical to ECMA-376 (see http://openiso.org/ECMA/376/Part4/2.18.101 ) in which copyrighted material is referenced only by name and without disclosing the material.
  13. Vague Conformance Clause for Conforming Applications. The approach used in the current draft of DIS 29500 is fatally flawed in terms of interoperability, as the conformance clauses create a situation where almost any application could be considered conforming. It allows 'cp', 'pkzip', 'cat' and even the 'Recycle Bin' / 'Trash' to be considered conforming OOXML applications.
  14. Revamped XML schemas have not been reviewed. The current version of the draft standard comprises three copies of the XML schemas describing the various markup languages that comprise OOXML: Normative XML fragments in the run of the text (to be moved into an appendix), full schemas listed at the end of the Markup Part, and annexes containing copies of the schemas. All of the schemas were duplicated in order to create a strict and transitional schema for each document type (word processing, spreadsheet, and presentation). These new schemas have never been seen, and have never been reviewed.
  15. OOXML does not provide the Binary to XML mapping which is required to fully represent the existing corpus of user documents. No other application supporting OOXML will be able to faithfully or fully recreate the look of Microsoft's legacy binary documents. Although the binary Office document specifications have been posted by Microsoft (15 Feb 2008), no standardized mappings were offered during the BRM, as requested by the US, United Kingdom, Brazil, and Malaysia, amongst others. Binary mappings explain how to translate a binary document into OOXML, or provide standardized guidance on how to "represent faithfully" legacy documents. Without standardized mappings, the same binary source document will produce different OOXML documents in Microsoft Office, Apple iWork, OpenOffice.org, etc., breaking interoperability and preventing the realization of OOXML's stated goal of preserving legacy documents.
  16. Macro functionality is not properly defined. Section 2.16.5.41 defines a "MACROBUTTON" field that allows the definition of a button in the document that will trigger a macro. But little is said about how the macro is stored, bound, what API's are available, or what the security model is for this feature. ECMA's disposition (approved in batch by the BRM without discussion or opportunity for objection), was something quite different and unsatisfactory. ECMA simply added: "The mechanism by which the command specified by text in field-argument-1 is located and/or executed by an application is "implementation-defined". Unfortunately, with this addition, not only is it impossible to have cross-platform interoperability of this feature, it is unlikely that vendors will be able to implement a reasonable security policy to detect, scan or block macros included in documents.
  17. Markets cannot rely on ISO standards with calculation errors. Spreadsheet formulas still result in calculation errors. Although the CEILING function was recognised to have a legacy bug and fixed during the BRM, there exist more mathematical inaccuracies in OOXML's spreadsheet function. The FLOOR function has been identified to have a similar mathematical inaccuracies for negative numbers. This is a problem that needs to get carefully studied. We recall that Intel faced a consumer scandal and losses when their new Pentium chip was found to have a calculation error. The Y2K problem, a standardization issue, resulted in billions of investment for damage control.
  18. OOXML still allows for 5 date types due to wording weaknesses. Although the issue with Dates was discussed and approved at the BRM, weak "standard terminology" is used to imply that only ISO 8601 is to be used. This leaves room for the serial numbered dates to be used in place. Thus eventually 4 different serial date types will conform as OOXML documents.
  19. There are even more technical errors. Fast-Track permitted the National Bodies to review the specification and submit comments but there was a deadline for the submission. The standard proponent obstructed the work in many national committees where participants wanted to see valid technical issues addressed. Some member states were for instance unable to vote and submit their comments. An impressive number of 3500+ comments survived the anti-comments campaign. NB need to keep in mind all the issues their own committee did not find and submit. Even ECMA submitted comments on their own proposed standard. Past the september ballot new issues emerged when participants read the documents again and looked for ways to resolve the comments. IBM reported to the US standard body: A random sample of 12 pages found 19 technical defects, with serious concerns such as: Storage of plain-text passwords in database connection strings, Undefined mappings between CSS and DrawingML, further errors in XML Schema definitions and dependencies on proprietary features of Microsoft Internet Explorer. None of this was raised prior to the September 2007 ballot and no new issues could be raised at the BRM.
  20. OOXML's poor quality would have a significant impact on SC34 in the coming years. It does not serve any National Bodies interest to approve and publish an ISO/IEC standard with significant questions about its quality and a complete lack of a finalized text. 'Defect Reports' and 'Requests For Interpretation' will completely swamp the ISO/IEC JTC1 SC34 participants and the national participants over the next 2 years with a substantial amount of administrative work and unfortunately diminish the perception of an ISO 29500 standard and, possibly, decrease the market acceptance of the standard.

Bonus

  1. Worst ECMA dispositions were approved: ODFA published a paper 10 Top Worst ECMA Dispositions prior to the BRM. All, unfortunately were adopted by the BRM. One only was adopted from actual discussion, and that was the 'Dates' issue. The rest got through via the wonderful virtue of the paper balloting.

Comments

Add a New Comment