Groklaw - India Has Voted NO to OOXML - Updated - On Error Rates in Draft Standards

	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

India Has Voted NO to OOXML - Updated - On Error Rates in Draft Standards

Thursday, March 20 2008 @ 12:33 PM EDT

I'm very happy to report that despite all the pressure to get India to change its vote, India has stalwartly voted No once again to OOXML. That will, I hope, encourage others to vote what they truly believe is right.

This will help you when you read the article on Arnaud's Open blog, "Let's be clear: The Apache Software Foundation does NOT support OOXML", written to counter all the stories Microsoft reportedly is telling governments and NBs about various companies and projects allegedly supporting OOXML.

Here's Arnaud:

Indeed, in its desperate and last minute attempts to convince National Bodies around the world that OOXML is happening anyway so they might as well support it as an ISO standard, Microsoft is eager to claim support by as many companies and organizations as possible.
As evidence, in its latest OOXML propaganda open letter Microsoft lists IBM among other companies as having “already adopted (or announced adoption of) Open XML in their products”. This, despite a clear explanation of the contrary by Rob Weir, published two months ago! Does anyone believe they haven’t seen it or heard about this? I sure don’t. And if there was any room for misunderstanding Bob Sutor’s statement filled that in.
A colleague in a foreign country even reported that in a National Body meeting he had been confronted by a representative from Microsoft who was trying to silence him via intimidation and insistence that IBM supported OOXML contrary to what he was saying.
Microsoft’s oversight of IBM’s denials is clearly not accidental. It is part of a well crafted and continuous disingenuous plan to convince NBs at all cost. There is already so much evidence of Microsoft going far beyond what most would consider normal lobbying behavior it is sickening. For one, I’m not ready to forget the case of the NGOs in India. Talk about dirty practices.
But what really is at the bottom of Microsoft’s claims is that basically any software that handles XML supports OOXML. While technically this is true to a certain degree, such a bold claim without any further qualification is pure misinformation.

There is a difference, in other words, between supporting XML, what you might call pro forma support, and supporting OOXML as a standard. For that matter, there is a difference between support for Microsoft Office 2007 and support for OOXML. They are not the same thing, so when OpenOffice.org announces native read and write support for Office 2007 documents, that is all it means. It doesn't mean OpenOffice.org supports OOXML as a standard. No matter what Microsoft folks try to tell you.

It's pitiful if the only way to get people to vote for your format is by confusing them with half-truths. Or worse. Misleading people about what is capable of running your software can get you sued, after all.

Update: On Error Rates in Standards Drafts

Here's something worth highlighting too, a reply to Rick Jelliffe from Jim Melton. Jelliffe had written this, pushing the idea that defects in a standard don't matter since they can all be fixed in maintenance:

I have blogged before On error rates in drafts of standards and I refer interested readers to that. Note that I give an estimate of the number of errors that your would expect to be caught (in one pass) at about 1,000, which was exactly what we have. In particular, note (ISO SQL Editor’s) Jim Melton’s comments, which I will repeat
Or perhaps most people were somewhat intimidated by the prospect of (thoroughly) reviewing a 6,000 page document. To put this in perspective for those who know SQL’s size and complexity, the sum of all nine parts of SQL is about 3950 pages. A ballot on SQL frequently receives several thousand comments, and we’ve been balloting versions of SQL for 20 years!
In fact, virtually every large spec I’ve ever had the “pleasure” to review leads to “thread-pulling”, in which every page yields at least “one more” bug, and following up on that one leads to more, and following up on those leads to still more, etc. I would personally be stunned if 30 dedicated, knowledgeable reviewers of a 6,000 page spec on its first public review were unable to find at least 3,000 unique significant problems and at least 40,000 minor and editorial problems. But that’s just me…
Under that kind of criteria that our Big Blue friend is proposing, the ISO SQL standard which is one of the most widely implemented and important and mission-critical of all ISO IT standards would not be of high enough quality to make the grade!

Melton replied in this comment:

Whoa, there, Rick. If you're going to quote me, then I want to be sure that the context is available to your readers.
One relatively important fact that didn't show up in the words you quoted is that the standardizers of SQL weren't so arrogant that we thought we could rush (and it's hard to deny that the phrase "Fast Track" implies hurry) 6,000 pages in one go, without it having not been visible to the vast, vast majority of the world until it started its FINAL ballot.
So, it took the SQL world some 20 years to write 4000 pages of standard, to root out the serious bugs (and thousands of smaller, mostly editorial, bugs at the same time), and to reach a genuine consensus on the content. I don't know Rob Weir, but I think it's misleading and unfair to extend what he said by concluding that SQL is not of sufficient quality to "make the grade". I do not believe that anybody thinks that there are still 200 serious errors remaining in SQL's 4000 pages, must less a thousand or two. Why? Simply because we have taken the time...years of it...to carefully root them out and fix them, giving the world at large plenty of time to review our bug-fixing efforts.
What I see DIS29500 doing is exactly the opposite. You've written 6000 pages of specification largely in secret (and, I understand, recently added over 1500 more pages) and given the world five months to read, absorb, understand, review, critique, and establish informed positions on it. Worse, whether it happened because of unreasonable methods, pure random chance, or genuine and unexpected interest, the fact that the size of the JTC 1 Subcommittee that was to vote on the document suddenly exploded gives the appearance that somebody was trying too hard to stack the deck...almost as though it wasn't really desired to have too much real review. Please note, I don't know any facts at all about the membership changes in SC 34, except that it happened. I'm not accusing anybody of anything, merely stating what people have inferred from those facts.
In my not-so-limited experience, if a 5-month (or 9-month) review of a 6000 page spec revealed "1027 unique issues", then a truly open process in which the document went through the normal WD, CD, DIS, FDIS process would almost certainly reveal upwards of 5000 unique issues. Also in my experience, fixing even 1000 non-trivial bugs is a very daunting process that takes many months, perhaps two or three years (given a reasonably high frequency of meetings -- say, three 3-week meetings per year).
In short, I want to emphasize that I think a Fast-Track process for any standard of this magnitude is a monumental mistake and a serious perversion of the entire concept. I was wary of that process when it was introduced, but saw that (initially, at least) it was being used for moving well-established, very widely implemented specifications into the ISO world for maintenance and possible additional development. Speaking solely for myself (and I EXPLICITLY disclaim any intent to imply an Oracle viewpoint, a USA viewpoint, or a North American continent viewpoint!), I find the whole thing appalling.
Jim
P.S., Please note also that I have taken no position at all on the merits of standardizing the technology in the spec, nor even the merits of the technology itself. I am ambivalent about whether the world community would be better served by one standard in this space or two or more (I know that the world is a Better Place for having one standard for relational database management, and a Better Place for having more than one standard for programming languages). I object solely to the process by which this has taken place.
P.P.S., Again, without making accusations about anything, are you aware that the international standards community generally views ECMA now as a wholly-owned Microsoft subsidiary? I offer no opinion about the validity of that view, but almost everybody to whom I have talked about ECMA dismisses it as little more than Microsoft's bought-and-paid-for channel for submitting documents for pretend standardization. That sounds a bit harsh, but that's what I hear.
P.P.P.S., One last thought and I promise I'll close: You refer in your text to "IS29500". That's rather premature, isn't it? At the time of my writing this response, the standard has not been ratified. So it's still DIS 29500 at the moment.
Jim Melton | March 20, 2008 08:44 AM

Maintenance is supposed to be for issues that come up *after* the standard is established, not to fix a bagful of problems no one had time to fix beforehand. If that is the "solution" to a Fast Track that ran off the rails, the proposed format wasn't suited to the Fast Track process, and it clearly needs more time and work.

India Has Voted NO to OOXML - Updated - On Error Rates in Draft Standards | 285 comments | Create New Account

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

Corrections (if any) here please

Authored by: nsomos on Thursday, March 20 2008 @ 12:37 PM EDT

Please place your corrections here.

It may be helpful if the Title were a
short summary of the correction.

mitsake->mistake

Thanks