Groklaw - Answering Paul Thurrott on OOXML

	When you want to know more...

Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines

ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

You won't find me on Facebook

Donate

No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.

What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments

Sponsors

Hosting:

On servers donated to ibiblio by AMD.

Webmaster

Answering Paul Thurrott on OOXML

Sunday, August 05 2007 @ 06:37 AM EDT

Paul Thurott thinks OpenXML is A-OK. After noting that Massachusetts has deemed it an acceptable document format, he says this about the overwhelmingly negative comments the Commonwealth received about OOXML:

Before arriving at this conclusion, the state reviewed almost 500 comments from individuals and organizations, most of whom complained about Massachusetts adopting the Microsoft formats....
It should be noted that while Microsoft originally developed the Open XML in-house, these file formats are now controlled by a standards community that answers to Ecma International. It's likely that most of those in Massachusetts who complained about Open XML adoption there were unaware of this relationship.

Actually, if you read the letters, you will see that they mostly show a very high level of factual information. The impression one gets is that they know perfectly well all about ECMA. They consider it a rubber stamp organization which has no such goal as control of OOXML. Even if it did have that goal, since it allows proprietary extensions in a "standard", the question becomes: will ECMA control those proprietary extensions? Obviously not. Therein lies the problem.

I'd like to show you some excerpts from just some of the letters. Unfortunately, Massachusetts didn't publish them on the website openly and in full the way I remember it doing when ODF was being considered. That's despite saying on the website in its announcing press release "All comments received are posted on this web site."

Posted, eh? Let's see. If you follow the link provided, this time you find you must download a PDF of some 800+ pages, and they have it locked up so it isn't possible to copy and paste, even though the comments started as emails, so Massachusetts took that added step of making them harder to read and reproduce. Also, since many entities sent their comments as attachments to a brief email, those attachments are not made available at all. So I have had to hand type these excerpts for you, which is truly ironic in this context. There is nothing I can do for you about the attachments if Massachusetts isn't in an open mood.

By the way, the link to those comments about ODF back in 2005 no longer works. They make them available now only as a PDF also, as best I can make out, and I had quite a time even finding that. Here it is, for the record, and I've updated our permanent ODF page, which tells this whole, ugly Massachusetts story.

A brief word about ECMA, first, to show you why folks might not trust it or its fast tracking of standards. First, may I point out that ECMA stands for European Computer Manufacturers Association? In other words, it's not a standards group representing the public's interest. Here's what Ecma itself says [PDF] about its purpose:

The goal of the Technical Committee is to produce a formal standard for office productivity applications within the Ecma International standards process which is fully compatible with the Office Open XML Formats.

So it was never about whether or not it qualified to be a standard. It saw its role as enablement. And in this paper, on page 22, Ecma describes its value to a vendor like Microsoft:

Offers industry a "fast track", to global standards bodies, through which standards are made available on time;
Balances Technical Quality and Business Value:
*Quality of a standard is pivotal, but the balance between timeliness and quality as well: Better a good standard today than a perfect one tomorrow!
* Offers a path which will minimise risk of changes to input specs
* A "safe haven" for IPR

"Minimize risk of changes to input specs" sounds like a rubber stamp to me. They are forthright in presenting their value as value to the vendor, not the public, a vendor who wants a format fast tracked and approved pronto. At least that's how I read it, and I'm sure I'm not the only one.

So, the folks who wrote letters to Massachusetts do know about ECMA; they just don't trust it to require a truly open standard or to control Microsoft. Here are some excerpts from the public's comments, so you can judge for yourself:

For this to be a truly open standard, the standards on which OOXML is based would have to be available in their entirety to everyone without the constraints of NDA's, covenants not to sue or anything else. All of its inner workings must be available without the need for any proprietary extensions or parts owned by any single company, so it will interoperate with all of the existing formats it purports to support and the way it does this will be open knowledge to all. As long as Microsoft controls any part of this and keeps it closed, it cannot be said to be an open standard.

Please adopt the ODF Open Document Format so that future computer users will be able to use any program to open and read and work on files created in the coming years.

It is time for the State of Massachusetts to establish a firm policy to say that "Open is Open" and anything else less than that is closed. OOXML, while partially and initially appears to be open, it's full implementation includes elements that are not open. Therefore, it is not a true open standard. ODF is fully open. ...Do you want legible information accessible to future generations, or do you want the information under the indirect control of a corporate entity?

The point of an open standard is that everyone can use it, and twenty years from now we will still be able to read historically important records. Microsoft refuses to participate in a truly open standard (ODF) and they have yet to actually explain this refusal. They could implement ODF easily and still offer backwards compatibility with legacy file formats, since those file formats belong to Microsoft.

We believe the inclusion of a second document format standard, with known interoperability issues with your existing standard is premature. ECMA 376 is only now undergoing an objective assessment of its ability to meet its stated goals of interoperability and enabling competitive implementations. Attached is a summary of SUn's position, developed over the last few months as a participant in the US National Body advisory committee, V1. In light of these findings, we voted against approval of the specification in its current form. This reflects our belief that these very significant shortcomings must be addressed prior to acceptance of ECMA 376 as an ISO sttandard.
Just as we believe that ECMA 376 has technical issues that should be explored more fully and addressed prior to becoming an ISO standard, we also believe that the impact of a policy including both standards should be far better understood than at present.
For example, in the case of ODF, the Commonwealth has carefully considered and ultimately adopted Sun's plug-in for ODF support in Microsoft Office applications to minimize application and desktop impacts. We would suggest further detailed study of the availability and operation of the various OOXML converters available to ensure that they meet the Commonwealth's needs, both in fidelity and impact on workflows and business processes.
We are also concerned that the high water mark on accessibility features set with ODF 1.1 may not be met with OOXML. ETRM v. 4.0 should not recede from this mark. Indeed, the Commonwealth insisted on ODF v1.1 because it addressed issues discovered by a peer review body of all experts and PWDs; such a body doesn't seem to exist for OOXML.

I think the government needs to use a document format that is independent of proprietary vendors and that can be implemented in free software.

I strongly support the use of ODF as the official electronic document format for the Commonwealth. Unlike Microsoft's OpenXML, it actually is an open ... standard. The real value of government documents should be their contents.... Using a standard like ODF means that the documents will always be readable, even if the software that created them is no longer available. Microsoft's format doesn't provide that guarantee....Using ODF ensures the availability of information that belongs to the people of Massachusetts.

I would like to express my support for the Commonwealth to decline the Open Office formats. I hope that this will reduce the excessive costs associated with using Microsoft products and will improve access to technology.

I am in college... I think you should use ODF... OOXML is the format that is going to be used by Microsoft and its partners....On the issue of translator itself, Microsoft did not build it and does not take credit for it. You only hear them say that such a translator exists you do not hear them say that they made it. Lastly such translators only work part way as not all the specifications are open even to those that sign NDA's.

The true test of a standard is whether there exist at least two independent implementations that successfully interoperate. All of the procedural requirements and formalisms of the standardization process are attempts to ensure this by process. They do not ensure success. There are numerous unsuccessful standards. Massachusetts should wait until there are two independently developed implementations that successfully exchange files. I know that PDF has met this test. I think ODF passes this test. OOXML does not yet pass this test.
Massachusetts should postpone consideration of OOXML until both of these are resolved. Microsoft can address the first issue. Only the decision of some second organization to independently implement OOXML can deal with the second. Massachusetts should also ensure that this second implementation is a genuinely independent implementation that does not depend in any way upon Microsoft components or other information that is not present in the OOXML standard.

As a participant in the US committee reviewing OOXML, INCITS V1, I had the opportunity to review the text of the OOXML specification and to discuss it with others. I am sorry to report that I found the OOXML specification to be full of errors and omissions. Of course, no technical document is perfect. But this one, in particular, is of far greater length (more than 6,000 pages) and of far lower quality than any I have seen before. If it has advanced this far in the ISO process it is because of vendor pressure, not because of technical merit.
What is the problem with a buggy standard? Interoperability suffers. That is the problem. There is no doubt that if everyone in the Commonwealth used Microsoft Office 2007 on Windows Vista, that their interoperability will be good. But as soon as we admit choice in applications and operating systems, then interoperability will only occur when all sides follow a common standard. So the technical quality of a standard (accuracy, comprehensiveness, level of detail, consistency, etc.) is directly proportional to the level of interoperability and the cost to achieve it.
The ISO ballot on OOXML will not end until September 2nd, after which a resolution process to fix defects n the text of the standard will take at least an additional 6-18 months. That is, of course, if OOXML gains ISO approval, something which is not certain at this point. So I would recommend a cautious approach, and wait for the ISO process to conclude, or conduct your own independent technical evaluation of the OOXML specification to confirm its technical quality before adding OOXML to your list. Ask other vendors: IS this something you can implement? Ask yourself: Will this truly give the Commonwealth the interoperability and choice that you desire?

I would like to register my oppostion to Ecma 376 (Open XML). The State of Massachusetts should seek ways to make its services and the information it publishes accessible to all its citizens, and not merely those who have purchased the correct version of the correct software on the correct platform. Fully open standards, such as ODF, have the best chance of fulfilling this promise. Proprietary and semi-proprietary formats impose a third party into communications between the State and its constituents....
Further, I am concerned about the cost to the State and to the Citizens of the State imposed by proprietary and semi-proprietary standards. As many have experienced with existing software, support for old file formats may be dropped after as few as one intervening version, rendering the old files inaccessible.... Even if a vendor drops support for a particular version of a fully open file format, everything needed to implement full support for that format is still available to the public.... With a proprietary or semi-proprietary file format, there is always some amount of information about the specification which the vendor keeps to themselves, and thus, some amount of data will always be lost when the vendor drops support for that version of the format.

The debate between the ODF and OOXML can be boiled down to this:
Microsoft has a virtual monopoly on making cars that run on Microfuel. Microsoft makes frequent changes to Microfuel so that old cars which are perfectly good no longer run and you have to buy a new Microsoft car. In addition the entry level model only costs slightly less than the fully loaded luxury model.
Someone has now invented Gasoline. Gasoline can be used to run a car built by anyone and its formalation is public knowledge and will not change. Microsoft could easily change its cars to run on Gasoline but has instead chosen to run its new cars on Microfuel Advanced. For certain consideration, which could change in the future, it will also allow competitors to create cars that run on Microfuel Advanced, although no competitor has yet created a car that runs on Microfuel Advanced. Microsoft also reserves the right at any time in the future to modify Microfuel Advanced and can't guarantee that competitors cars will be able to run on modified Microfuel Advanced.
Microsoft has chosen to have its cars run on Gasoline. Microsoft is lobbying hard to have Massachusetts cars run on Microfuel Advanced. Which fuel would you rather have your car run on?

Microsoft has done its level best at obfuscating its reluctance to freely produce details regarding its proprietary document formats. To not produce these details is to disallow ANY other party the ability to implement a competing product....
And to allow ECMA 376 to become a "standard" would be tantamount to signing off on a blueprint that doesn't show where the plumbing or electrical are in a building!

I am concerned that the Commonwealth is considering the inclusion of ECMA 376 in theun Enterprise Technical Reference Model....As a resident and taxpayer of Massachusetts for more than thirty years, I am deeply troubled that a proprietary format as described in ECMA 376 would be included in a policy intended to make documents broadly available in perpetuity.
ECMA 376 is (at best) an incomplete definition and arguably unworthy of the label 'standard', given the haphazard descriptions and obtuse language used to conceal the proprietary elements in the description. A standard, by definition, should not be proprietary. The very reason for a standard is so that multiple parties may conform to an agreed list of specifications. this result is simply impossible in ECMA 376.
It is virtually assured that certain documents conforming to ECMA 376 will become unreadable in future years, which will either render the affected documents useless or require a massive outlay of tax dollars to convert to an updated document definition. The ODF standard documents do not share this potential liability.

People with disabilities... require their software to make adjustments to how the content is displayed.... Developers of software for these purposes have to specialize for the document format, as well as for the target population, which is often very small. With two standards, rather than one, there will be a need to solve two such software problems for every population, resulting in a loss of quality, speed and availability of software development, spreading a niche industry very thinly.
Besides the problems of multiple standards, ooxml has serious accessibility flaws. It fundamentally lacks semantic information to make it possible to reformat content without altering the meaning. A simple example is that in data entry forms, it lacks a link to connect the form labels to the corresponding entry areas. The reshuffling of elements that can happen with zooming, a small screen, or reading aloud with a screen reader, is impossible to do correctly without this information.

Well, that's just a sample. Do they sound like they lack accurate information? They just don't know about ECMA?

By the way, I assume, since there are issues raised here regarding OOXML with respect to accessibility for the disabled that we will see hearings on this very serious matter, as we did on whether ODF met the needs of the disabled.

Hardy har. I know. This is all just dancing baloney. Or in Microsoft's Jason Matusow's immortal words in the context of IBM and Sun being excluded in Portugal from the Technical Committee voting on whether or not to approve Ecma 376 as an ISO standard, "There is no question that all over the world the competing interests in the Open XML standardization process are going to use all tactics available to them within the rules." I take that as a Microsoft admission, since all I'm hearing about is Microsoft trying every trick in the book. No one else is making such headlines.

Massachusetts, of course, is Exhibit A showing the Microsoft version of standards setting.

Answering Paul Thurrott on OOXML | 285 comments | Create New Account

Comments belong to whoever posts them. Please notify us of inappropriate comments.

Corrections Here Please

Authored by: dobbo on Sunday, August 05 2007 @ 06:51 AM EDT

Post your corrections below so PJ can find them.