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

Posted by Sander_Marechal on Mar 26, 2008 2:15 AM
LXer Linux News; By Sander Marechal ('s-Hertogenbosch, The Netherlands)

LXer Feature: 26-Mar-2008

This is a response to Patrick Durusau's recent letter Who loses 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. Read more to find out why.

Updated on 26-Mar-2008 12:34 PM I emailed a copy of this article to Patrick and he responded. I have posted his response at the bottom of the article.

This article on Digg


Updated on 26-Mar-2008 12:34 PM 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 not an 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 approving 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 is 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. (its 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 authoritative. 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:



Sander,



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.



Patrick



So posted.



This letter is licensed under a CC-by-sa 2.5 license. You are free to copy, redistribute and change this letter as long as you follow that license.

Return to the LXer Features

Subject Topic Starter Replies Views Last Post
Patrick Durusau's response Sander_Marechal 52 3,849 Mar 29, 2008 2:53 PM
A very well reasoned response davescafe 1 3,243 Mar 26, 2008 11:15 AM
Untitled softwarejanitor 0 2,870 Mar 26, 2008 9:56 AM

You cannot post until you login.

LXer

  Latest Features
Scott Ruecker (San Diego, U.S.): Linux That's Small
Oct 14, 2024

penguinist: Encryption, Trust, and the Hidden Dangers of Vendor-Controlled Data
Aug 27, 2024

Scott Ruecker (San Diego, U.S.): My Linux Mint Tribute
Aug 23, 2024

Scott Ruecker (San Diego, U.S.): How I Turned My Chromebook Into A "Mintbook"
Jul 08, 2024

Scott Ruecker (San Diego, U.S.): Adventures With My New Chromebook
Jun 10, 2024

Scott Ruecker: My Linux Laptop
May 08, 2022

Scott Ruecker: Laptop Dual Boot Project: Part 2
Nov 30, 2021

Scott Ruecker: Laptop Dual Boot Project
Nov 30, 2020

Scott Ruecker: Lenovo Laptop Love..Not!
Nov 01, 2019

James Dixon: Attempting to install Linux on a new laptop, a follow-up
Sep 21, 2019


View all

  Search Features

Search LXer Features:

[ Copyright © LXer | All times are recorded in Central Daylight Time (CDT) ]

[ Contact Us | Privacy Policy | Terms of Service | About us | rss | Mobile ]

Login