« Why OpenDocument Format matters to Texans | Main | Microsoft Fights for Office Open XML Standard Approval »

Tuesday, 03 April 2007



I'm not sure why decoupling the file format from the application is all that important. How many different people are writing application suites anyway? Basically only big companies have the resources to do so, and maybe some of the largest-scale OSS projects like KOffice. In any case, one would want one's file format to contain all the information that's needed in a logical, easy to get at, manner and as little extra information as possible to speed parsing.

It seems impossible and pointless to try to standardize both the display and content of editable documents (I don't think ODF tries to standardize display and OOXML explicitly contains some tags which describe display methods but which are not described like doSomeCrapLikeOldApp). If you do standardize the display, then there is absolutely no room for office suites to be different from each other.

If you have different semantics for the same elements, as you would have to for office suites to handle things differently in any significant way, then it's worse than having different sets of elements in the first place. It's far more confusing for an element to mean a different thing depending on which suite created it, and these suites have vastly different internal architectures so meanings /will/ be different. So any particular organization will standardize on one office suite so that multiple people can edit and print documents and still be assured that they will look exactly the same.

Given the fact that Office suites will be standardized within an organization, it makes sense to have different formats for each suite. We just need some lingua franca formats which can be used between different organizations. Thus, there's no real need to harmonize OOXML or ODF. Having OOXML and ODF as open standards does ensure that converters can be written between them and any other document format one would wish. I think it will be difficult for applications to be both differentiated and support a single standard. Thus, I see ODF either splintering as more people implement it, or new implementations of ODF being almost entirely identical to older ones in terms of features and style.


Nks, that makes about as much sense as having different file formats for different web browsers. But if we had that, there would be no World Wide Web. Your argument is in reality an argument against having standards.

And the issue is not just about office suites. A wide range of applications support the open document standard. See http://opendocumentfellowship.org/applications (.) Just as having the standardized HTML file format for the Web led to a proliferation of applications that read and write that format, OpenDocument is sparking a renaissance of development in the office productivity space.


The OASIS committee was created for making an open format for OpenOffice. It was not created for making an ISO standard Office document format.
The chairman of the TC even signed it's messages with OASIS Open Office TC.

There is no indication that at the start of this committee (when there was still a relevant participation to be made) Microsoft was asked to join and contribute. The only document that revers to participation at that time is a "Call to participation for the Open Office XML format TC" only one month ahead the start.
Also the OASIS TC never considered compatibility with the format of the market leader which already had an XML format in existance at the time of the TC start.

Was Microsoft ever seriously considered as a participant in the standardisation of the Open Office format in 2002 ???

The formats are hardly the same and/or easy to be made compatible by extending.
OOXML is a lot more hierarchical structured format with its markup created in child and parent structures whereas ODF lacks this structure making it more flexible to combine all kind of markup structures and much harder to fully implement as all this flexibility has the potential for extreme complexity.

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Your comment could not be posted. Error type:
Your comment has been posted. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.


Post a comment

Your Information

(Name and email address are required. Email address will not be displayed with the comment.)