decoration decoration

When you want to know more...
For layout only
Site Map
About Groklaw
Legal Research
ApplevSamsung p.2
Cast: Lawyers
Comes v. MS
Gordon v MS
IV v. Google
Legal Docs
MS Litigations
News Picks
Novell v. MS
Novell-MS Deal
OOXML Appeals
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v Novell
Sean Daly
Software Patents
Switch to Linux
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.

To read comments to this article, go here
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 announces native read and write support for Office 2007 documents, that is all it means. It doesn't mean 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 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.


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.

  View Printable Version

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )