17 February 2007

OOXML hoax 1: The spec is too long.

The Office Open XML specification is around 6000 pages long compared to the OpenDocument specification which is only 800 pages long.

Issues are taken with the fact that it would be to long to implement by other parties and it would be to long for the ISO fasttracking procedure to evaluate the specification.

Firstly I will go into the fact that the spec would be to long to implement.
The OOXML specification is meant to support the features of the biggest Office application and be compatible with the billions of documents produced by that application in the last 15 years.
Ecma and Microsoft think that requires 6k pages. I think they are probably short.
No one can implement such a complex spec on just 6k pages.
Luckily they can use MS Office 2007 document as a reference.
But the ODF spec then with its 800 pages ?
A big advantage of the ODF spec is that they do not need truly faithful support for their existing documents as much as OOXML does with probably 99% of Office documents being created with MS Office. OOXML spends at least 1000 pages on compatibility especially with adding the VML spec.
Also the ODF spec isn't really 8800 pages to implement is it:
Here in the bottom of this article by Miquel de Icaza http://http//tirania.org/blog/archive/2007/Jan-30.html it suggests, with reusing several w3c standards and with OOXML using a bigger line spacing in the specs, that implementing ODF specs would cost almost the same amount of actual specification to be implemented as OOXML.

Let's face it. Building an complete Office application with all the trimming is a very very big task no matter what. It is unlikely that more than a few original application will ever exist that can fully use both ODF and OOXML formats and it takes big projects to make that happen. And I bet that any such project would rather have double the spec size to describe the specs even more precise than have less documentation to work with.

Secondly several parties notably IBM and Groklaw and claimed that the 6000 page OOXML spec cannot be evaluated by ISO national bodies in the short time of a fasttrack procedure.
Let's first look at the fasttrack procedure. How long is it ? The shortest possible time for a fasttrack procedure seems to be about 8,5 months with the average probably closer to a year if the standard is undisputed. Disputes can lenghten the time even more.
Still it would be quite a short time if everyone had to evaluate every page carefully for each little item on it. But is that necessary ? No, not really.
A fasttracking procedure is a procedure for a standard of existing technology. The standard is has been developed and maintained by a third party. It is not a brandnew developement that is unproven and does not require the same amount of scrutiny. Also in the period prior to the standardisation process ISO already advises the third party on how to make the standard acceptable for ISO standardization (ISO had a liaison in the Ecma technical committee for instance and the OOXML draft documents were already provided to ISO from may 2006 onwards).
Fasttracking is more a descisionmaking process than a development process.
In fasttracking ISO national bodies can look at the usefulness and the need for the standard, can look at if the standard does not contradict an ISO standard and the overall quality of the standard. Sometimes amendments/alterations /clarification might be suggested and can be made by the third party in charge of the standard.
Although there might be some minor issues it seems clear that the only really important question in the fasttracking proces of OOXML is whether this new standard contradicts the ODF ISO standard. For the minor issues Ecma can make alterations or give a road map in which versions and when the alteration can be made (similar to adding formula's in ODF mayby).
For the contradiction with ODF you do not need 6000 pages. You need to look only at some small parts of the specs specifying the essentials of the OOXML spec. In fact you need only look at the Part 1 (Fundamentals) and the part 3 (primer) parts of the specs to evaluate the specs for a decision making process. These parts (550 pages) describe the goals, the basic ideas of the specs, the conformance, in short everything to determine the need and usefulness of the standard format.

I think that the basic idea of the OOXML spec lies in continuation, stability and compatibility and in opening up the legacy office data. These are the powerful arguments that form the basis of the OOXML standardisation process. The should not be underestimated. Governments, organisations and companies and individuals have invested a lot in Office documents in the last 15 years.

The Wraith


Anonymous said...


I fully admit that 6k pages are not too much in absolute terms. But 6k pages are *very* much for a fast track standardization process, knowing that the standardization bodies have limited resources. But it's a transitional problem only, and it's not the point.

The real concern is (indirectly) pointed by this sentence: "The OOXML specification is meant to support the features of the biggest Office application and be compatible with the billions of documents produced by that application in the last 15 years."

In my opinion, the compatibility with the billions of docs produced by Office in the past is a job for Office, I mean the Microsoft Office application software (2007 and leter). On the other hand, OOXML is a file format specification for the future. As long as Office can work with the old and the new formats, everything is OK; the link between the past and the future is provided by the office sotfware. There is no need for a similarity between the new and the old, because we don't need to use the OOXML schemas to edit the old .doc/.xls/.ppt files.

Anonymous said...

6k pages are *very* much [too much] for a fast track standardization process

As the main point of this specification is to be compatible with millions (billions?) of documents produced over many years, allowing a few more months to get it right wouldn't kill anyone - giafly