A response to Patrick Durusau: Who Loses If OpenXML Loses?

by Sander Marechal

Updated on 2008-03-26@17:34 I emailed a copy of this article to Patrick and he has responded. I have posted his response below.

This is a response to Patrick Durusau's recent letter Who loses if OpenXML loses? (PDF). Before I discuss the various points that you make in your letter there is one thing that I would like to say; I find it shameful that you, Patrick, makes these kind of statements without a proper disclaimer that this is your personal opinion and not the position of the ODF committee (for whom you edit the ODF specifications), the V1 or any other technical body that you represent. In fact you seem quite happy that the media is running with headlines like “The ODF editor says…” else you would have done something about it after your previous publications. To lead by example:

The opinions expressed in this letter are my own. They do not necessarily represent the viewpoint of LXer Linux News, nor the viewpoint of my employer Tribal Internet Marketing. They do represent the viewpoint of The Lone Wolves Foundation though.

Now, back to your letter.

1) National bodies lose an open and international forum for further work on DIS 29500.

Which open and international forum? DIS 29500 is scheduled to be maintained by Ecma (PDF). Office Open XML is already an Ecma standard: Ecma 376. So the community can already work with Ecma on future revisions of that standard. Approving DIS 29500 does not change the venue in any way. It only changes the name of the standard.

The only circumstances under which this statement can be true is if Microsoft has announced to stop supporting Ecma 376 all together unless it is approved as DIS 29500, but promises to work on the standard if it does get the ISO stamp. This is obviously not true because Microsoft has already stated that it cannot commit to whatever comes out of Ecma, regardless if it's DIS 29500 or Ecma 376 they are working on. From the mouth of Brian Jones:

it's hard for Microsoft to commit to what comes out of Ecma in the coming years, because we don't know what direction they will take the formats. We'll of course stay active and propose changes based on where we want to go with Office 14. At the end of the day though, the other Ecma members could decide to take the spec in a completely different direction.

Your point can also be interpreted in a different way. Perhaps you are arguing that Ecma is no open forum but only ISO is. If that is true then it's obvious that DIS 29500 should not be maintained by Ecma if it is approved. It would also mean that Ecma 376 is nothing more than a rubber stamp on a stack of documents submitted my Microsoft and that Ecma 376 should never have entered the fast track process in ISO. I'd go further and state that if Ecma is not an open forum then it should be barred from the fast track process at ISO all together.

Your second point makes little no no sense at all:

2) Microsoft based third-party vendors may be excluded from contracts because Microsoft has no ISO approved format.

First: ISO and its national bodies do not owe any company a living. Second: There are no third-party vendors that implement DIS 29500. The best you get is a few third-party vendors that support a few parts of Ecma 376. Third: The primary concern for third-party vendors is interoperability with Microsoft Office. They can already interoperate with Microsoft Office by implementing Ecma 376. DIS 29500 adds nothing in this regard.

What you are really saying is that not appriving DIS 29500 means that Microsoft itself will lose out on certain contracts. This has some effect on third-party vendors as well of course. If some company or government body does not use Microsoft Office then they will not have much need for third-party tools that implement Office Open XML. Again the answer is simple: ISO does not owe Microsoft a living.

But the point above is of course why Microsoft is trying to ram Ecma 376 through ISO in the first place, isn't it? If Office Open XML does not have an ISO stamp of approval and OpenDocument Format does, then it's plausible that government bodies over the world will mandate ODF support in their IT procurements. Since Microsoft is not willing to implement ODF support in Microsoft Office it's very likely that Microsoft Office cannot fulfill those procurements. Yet again the answer is simple: Governments do not owe Microsoft a living. It's Microsoft's problem and not the government's problem. Microsoft can easily avoid this situation by implementing full support for ODF in their Office suite.

Proof of my point can easily be seen in Microsoft's requirements that any change that ISO or Ecma make to DIS 29500 does not break support for Office Open XML as currently implemented in Microsoft Office 2007. From Yoon Kit on the OpenMalaysia blog:

We eventually found out that if any changes affected current implementations it would certainly be rejected.

If Office Open XML passes ISO certification but its specification is incompatible with Microsoft Office 2007 then Microsoft will have gained nothing. Governments will procure for ODF or OOXML support but since Microsoft Office 2007 then does not implement either, it still cannot fullfill the procurement. This is the sole reason for DIS 29500: Maintaining the Microsoft Office cashcow. On to your third point:

3) ODF has no ISO-based formula definitions to insure compatibility between OpenDocument and OpenXML.

Approving DIS 29500 does not change this in any way. OpenDocument Format 1.2 is already on its way and it will handle spreadsheet formulas in its own way. What is needed here is a mapping between Ecma 376 and ODF 1.2 spreadsheet functions. DIS 29500 does not contain this mapping. Moreover, we do not need DIS 29500 to create this mapping. We can create it from Ecma 376.

OpenDocument currently lacks formula definitions for spreadsheets. (To appear in OpenDocument 1.2.) Many core financial functions in spreadsheets are undefined except for actual Excel output. That output varies by version and service pack of MS Office. What happens if OpenDocument and OpenXML reach different definitions of those functions?

This makes using Excel for financial calculations outright dangerous. It's a big vote against Microsoft Office. And if all those variations and inconsistencies are in the DIS 29500 specification then it's a big vote against DIS 29500 as well.

4) ODF has no ISO-based definition of MS legacy features for an ODF extension.
OpenDocument does not presently support legacy features of Microsoft formats. That will be easier with a formal definition of those features. Without OpenXML, OpenDocument has no authoritative definition of those legacy features. That delays OpenDocument supporting them in some future release.

DIS 29500 does not need to be approved for this. Ecma 376 as it stands already formally defines these features. If DIS 29500 does not pass ISO then Ecma 376 is authorative. OASIS and ISO can use Ecma 376 to create possible extensions to ODF.

5) ODF has no ISO-based definition of the current MS format for mapping purposes.
OpenDocument does not have a robust mapping to the current Microsoft format. That requires an OpenXML that has completed the standards process. If OpenXML is unclear, it must be fixed in order to create a robust mapping between the two.

First: DIS 29500 does not provide such a mapping. The current Micrsoft formats are the binary formats. What is required is a mapping for those binary formats. Second: If such a mapping is ever made then there is still no need for DIS 29500. Ecma 376 is good enough for that. Third: If Office Open XML is unclear and needs fixing then it should be disapproved now. That way Ecma can resubmit it through the normal (non fast-track) ISO process where enough time can be spent fixing it. Fast track is no place for a flawed standard.

The bottom line is that OpenDocument, among others, will lose if OpenXML loses.

The only one who loses if DIS 29500 fails is Microsoft, whose Office 2007 cashcow will run into trouble. Everyone else, including the OpenDocument Format, do not need an ISO stamp of approval on DIS 29500. The current Ecma 376 standard, flawed as it is, is more than enough to work with. Putting an ISO stamp of approval on that document does not suddenly make it “more interoperable” or a better spec. Unless Microsoft stops working with Ecma, but that is not ISO's problem. It's Microsoft's and Ecma's problem. Besides all that, Ecma can still resubmit Ecma 376 through the regular ISO process and gain approval in a few years when the standard has been properly reviewed and fixed. That's too late for the Microsoft Office cashcow of course, but that is not ISO's concern.

The world does not need DIS 29500. Ecma 376 currently provides the exact same benefits well enough.

Update: Patrick Durusau has sent me a response to this article:


Since I have spent the last six years of my life working on and improving the ODF standard I feel no need to formally respond to your obviously ill-informed post.

I have spend the last six years working on ODF, posting corrections to every version, leading the new metadata work, and now work as the TC editor. I don't have to answer questions about my commitment to ODF from you or anyone else.

You can publish that as my response if you like.


So posted.

This letter is also posted on LXer Linux News. This article on Digg

Creative Commons Attribution-ShareAlike


#1 Frank Daley

Microsoft stands to lose tens of billions of dollars in annual revenue should Microsoft Office have to compete on price and features, rather than lock-in.

It is therefore not surprising that Microsoft has targeted thousands of key decision makers throughout the world in its desperate campaign to bulldoze a flawed document for approval as an ISO standard.

Microsoft's deception campaign against Patrick Durusau will go down in the information warfare text books as one of the best executed campaigns in contemporary non-military information warfare.

From the muddled logic of Patrick Durusau's essay it is now quite clear that the deception campaign has been astoundingly successful.

Comments have been retired for this article.