Open Malaysia

Those that have been involved in National Bodies worldwide in the latest standardization exercise involving  Microsoft OOXML may have been puzzled at first, then later amused, that Microsoft representatives have chosen to rewrite not only well accepted definition of contradiction but also portions of technological history.

We will debunk Microsoft's latest assertions in this blog post.

To start off, let us accept that by virtue of accepted historical evidence, this new definition on the term 'contradiction' has only been suggested by Microsoft and Microsoft only. We will also note that this new definition has not been approved by JTC 1.

In light of the many contradictions submitted by concerned members at various National Bodies worldwide, Microsoft representatives have, in an act worthy of a team of scheming lawyers, decided to change the playing field by changing the definition of contradiction so as to invalidate the contradictions submitted by concerned members.

Let us look at their definition of contradiction:

"Does not disrupt nor prevent the coexistence with any existing ISO standard"

"[Contradictions] are really technical issues that should be raised in the next phase of the process"

To illustrate this point, Microsoft picks on two sets of areas of standardisation: "Programming Languages" and "Document Formats" to "prove" that this strange definition is consistent. The following sections will explain why their examples of "contradictory" ISO standards are fallacious.

C, C and COBOL as examples of contradicting standards in ISO

The examples Microsoft has used for the evidence of coexistence of yet "competing" standards are the ISO standards for Programming Languages:

• ISO 9899 for C
• ISO 14882 for C
• ISO 1989 for COBOL

This is their "proof" that their version of "contradiction" means that:

• Coexistence of competing multiple standards are allowed
• Overlap of standards are allowed
• First standards to the door does not win

This form of argumentation is completely fallacious as it draws a similarity of purpose between these programming languages. It was not noted in Microsoft's presentations that all three of these languages were designed for completely different purposes and that they are used in completely different markets.

The C programming language is a general-purpose, procedural, imperative computer programming language. The C language is widely used for systems programming. By comparison, C is sufficiently different as it was designed around the concepts of object-oriented and generics programming with static typing. C is most popularly used in building graphical applications. Finally, COBOL was designed from the start for the business domain and shares little with either C or C in its structure.

As such, these standards do not overlap in the substance of their specifications.

Given the many allusions by Microsoft that ODF supporters are undermining MS OOXML, the Microsoft team was clearly told that the reasons for standardising C and C and COBOL were NOT because of an ISO battle between programming languages in the ISO level, but rather due to the original intent of standards which is to standardise the programming language to prevent fragmentation in the market.

There were originally many implementations of C and C as each vendor provided different features. Every single one of these vendors provide different compilers that worked differently enough to make a software developer aiming at portability to tear his or her hair out. To promote better use and interoperability, the need for standardisation of these languages was created.

In addition, contrary to what was purported by Microsoft representatives, the purpose for standardization was not because the C team wanted to do a one upmanship on the C team. The only purpose for standardisation was to retain consistency between the different implementations by different competing vendors.

Finally, C, C and COBOL programs are typically are not exchanged between end users in the sense office documents are exchanged. Given the increased degree of cross-user interactions with electronic documents, there is a clear need for a single clear standard in this area. Careful observers will notice that MS OOXML is geared towards fragmenting the current ISO standard on Office Documents. We cannot afford fragmentation in document standards simply because a document format today facilitates a large degree of interaction between users on many different systems. A single document format will facilitate interoperatibility across many systems, much in the way that TCP/IP provided for the foundation for the Internet. Thus, the comparison to C, C and COBOL is misleading, false and unsubstantiated.

PDF, HTML and ODF as examples of contradicting standards in ISO

In addition, Microsoft argued that given the existence of PDF, HTML and OpenDocument Files within ISO "proves" that competing formats of documents are acceptable:

• ISO 19005-1:2005 PDF
• ISO/IEC 15445:2000 HTML
• ISO/IEC 26300:2006 ODF

They argue that these three ISO standards show that there are already a history of multiple standards in the area of document standards. While no unreasonable person would be against the possibility of multiple standards if the standards in question are sufficiently different, it must be noted that PDF, HTML and ODF address sufficiently different needs in electronic documents.

PDF files are most appropriately used to preserve the exact look of a document in a device-independent way. HTML, on the other hand, is a lightweight markup used in web pages to describe content. Neither is used for describing and facilitating the editing of documents, spreadsheets and presentations! Nobody in their right mind would use PDF or HTML for office documents. That is the sole domain of ISO/IEC 26300:2006 (ie, the OpenDocument Format - ODF).

To claim that PDF and HTML are examples of "multiple standards in the same area" is a gross miscommunication of ideas and an insubstantial red herring. This deliberate misunderstanding is similar to the C/C "justification" and is being used to convince the National Body to believe that ISO allows contradictory standards which "do the same thing"

Direct Contradiction to ISO 26300

Finally, ISO/IEC 26300:2006 already exists as an ISO standard and MS OOXML is a significant contradiction to ISO's motto of

"one standard, one test, and one conformity assessment procedure accepted everywhere.”

Both ISO 26300 and MS OOXML standard have identical aims to provide the functionality of

"text documents, spreadsheets, drawings and presentations for office applications."

Microsoft has never explained nor bothered to convince "Why Ecma 376 does not contradict ISO 26300", even when pressed multiple times. Instead they resorted to adjusting the meaning of the term "contradiction".

Microsoft has also never explained satisfactorily why MS OOXML is superior nor the different requirements it facilitates for over ISO 26300.

First through the door wins?

Finally, Microsoft argues that there should not be competition between standards such that the first standard through the door wins. For once, we agree with Microsoft. The first standard through the door does not and should not "always win". If the first standard is proven insufficient, it will be discarded. However if it is extensible, then new incoming standards should look towards harmonizing with existing standards.

In this case, the first standard is ISO/IEC 26300:2006. Fortunately for future applications, it is extensible so "new" standards such as MS OOXML should work towards harmonizing with this existing standard to prevent proliferation and confusion in the Document landscape.

There is certainly precedence in this area. China's Uniform Office Format (UOF) standard for document format is already in the process of harmonizing with ODF within OASIS.

In Conclusion

National Bodies worldwide, and JTC1 themselves, should focus on the technical substance of the contradictions submitted. We should be discussing the contradictions, and not Microsoft's definition of contradictions. This is a red herring, a means of diverting attention from the actual technical issues with the proposed standard. We should not be waylaid by the latest attempt from Redmond. We have the responsibility to ensure that the due process is followed strictly in the interests of all parties concerned, not just Microsoft.