The Dude abides.

The Tak Nak OOXML Campaign

It seems that the <NO> OOXML (”<TAK NAK> OOXML” in Malay) site is gaining incredible popularity. At last view, it has 13058 signatories. I remember that earlier this week the number stood at only 3000 signatories. Clearly, there is strong interest in ensuring that this standard is not ram-rodded through ISO.

As the balloting date for Microsoft OOXML draws nearer, National Bodies worldwide will be deliberating on how to vote on this standard. As Malaysians, we who wish to state objections to OOXML in its current incarnation should do so ASAP to SIRIM and through the petition as well. The link to lodge the objection through the petition is here.

Some of us have been looking at the Microsoft OOXML specification deeply in the past few months. As these things go, part of my day-job requires manipulation of documents so I could justify the time spent on looking at the specification as part of the daily grind The long and short of the analysis is a deep shudder of dread. There are serious problems with the standard which makes implementation and use practically impossible for third party implementators:

• At over 6000 pages, the standard is a behemoth! It literally becomes impossible to implement the standard correctly. In practical terms, this means that there will be a plethora of in-operable files created by office software because it’s literally impossible to build software that can implement 100% of this standard. Not the developer’s fault though - who can fully and correctly implement a 6000 page standard? Even Microsoft Office 2007 fails to implement Microsoft OOXML correctly!

The state of being begs the question: is the sheer length really needed? Microsoft claims that the length is to ensure 100% backwards compatibility with existing documents. However, a quick examination of the standard shows that this analysis does not carry merit. What does backword compatibility mean? To a layperson, it would mean that new software will be able to read and write older documents, right? Does Microsoft OOXML provide this capability? NO! Microsoft OOXML provides no information about how to read and write older documents.

In fact, all that’s provided in the standard are XML tags such as autospaceLikeWord95 and linewrapLikeWord6. If I was a developer today, should I somehow know how Microsoft Word 95 implements auto spacing or how line wraps are implemented in Microsoft Word 6? Of course not - there is no documentation available out there that defines this implementation! Thus, the argument that Microsoft OOXML provides backward compatibility carries no merit.

• Lack of reuse of existing standards. Part of the reason why Microsoft OOXML is so big in size is because it chooses to re-implement its own standards. Microsoft OOXML does not use existing hashing algorithms, or date representation standards or language representation standards or even existing widely used vector graphic de-facto standards backed by W3C.

Instead, Microsoft OOXML implements its own hashing algorithms (whose strength is not unknown due to lack of analysis by the security community), its own date representation system (which even conflicts with itself as Microsoft OOXML specifies two different methods of representing dates in different parts of the document!) and even languages (there is an existing standard on languages by ISO but Microsoft OOXML chooses not to implement it).

For vector graphics, Microsoft OOXML actually specifies the use of two different approaches in the same standard. First is VML, the proposed standard rejected by W3C in favour of SVG. Second is a method of implementing vector graphics that has never seen light of day before.

Does it makes sense to accept what amounts to a rejected standard and an unknown standard when existing widely-used standards already exist in the area? (To developers: yes, this means you will end up writing libraries to handle these vendor specific standards, instead of using existing mature bug-free libraries! Job security, anybody? :))

• Use of bitmasks. XML has many benefits, one of those being the ability to transform documents. Document transformation use well known XML tools such as xslt. These tools work on the assumption that representation is … well … in XML. Microsoft OOXML takes the unique step of representing many parts in the standard as bitmasks. Bitmasks are used for quick binary manipulation when using the C language, and it clearly doesn’t make sense in an XML context. XML tools such as xslt don’t work well with bitmasks, yet they are littered all over the standard. One could be forgiven for thinking that Microsoft OOXML is nothing more then a memory dump of Microsoft binary formats!

• Use of proprietary standards. Microsoft OOXML actually specifies the use of Windows Metafile Format (WMF) and Microsft Enhanced Metafile (EMF) for clipboard formats. These formats are proprietary Windows formats, which makes it impossible for those on alternative platforms such as Linux to use Microsoft OOXML.

More unfairly, the “optimizeForBrowser” element specifically targets Microsoft Internet Explorer. What about Firefox users on Windows? Hell, what about Opera users? Is it fair for an ISO standard to unfairly promote a specific vendor product line?

There are many other technical problems with Microsoft OOXML noted by observers worldwide. Which, of course, begs the question: why are we rushing to validate this fast-tracked standard? What’s the urgency? Isn’t it more important to work out the substantial issues at stake before accepting this as an ISO standard?

Some may view this post as a typical anti-Microsoft post and ignore the substance of the arguments put forward. Others may posit that as a Free Software and ODF advocate, I’m somehow biased. They too are ignoring the substance of the arguments I mention here.

I’m not objecting to Microsoft OOXML because it comes from the heartland of Redmond. I’m not even objecting to Microsoft OOXML because it is potentially a rival to ODF. None of those reasons matter to me.

The only thing that matters to me is that, at the end of the day, I should be able to open and share documents on my Linux box without having to worry about compatibility issues. I should be able to participate fully on websites without having to search for a Windows box. I should be able to develop and extend my existing software to support the document format in reasonable time without being forced to use a particular platform.

Microsoft OOXML affords me none of these capabilities in its current incarnantion, and thus, I reject it.