decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
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
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
Alex Brown: OOXML Revealed "JTC1 Procedures Were Rubbish" -- Sure Enough, Problems Surface - Updated
Sunday, April 12 2009 @ 04:50 PM EDT

Alex Brown recently tweeted to Microsoft's Doug Mahugh the following about OOXML:
OOXML=tought [sic] fights; revealed JTC 1 procedures were rubbish.
The OOXML approval was marred by procedures that were rubbish, eh? How about the result, then? Wasn't that exactly what the four appeals against adoption of OOXML stated as one basis, that the process was essentially rubbish? Were they right? One year later, it seems there are indeed some problems. Brown tells us on his blog that at the BRM "a number of existing Ecma-376 documents were unintentionally made invalid against the IS29500 transitional schema".

Oops.

The UK, he writes, now is suggesting a retroactive fix to undo the changes made at the BRM. Say, what? Rubbish though they be, is there any JTC1 procedure that makes *that* an appropriate way forward? If so, why bother to even meet? Just let Microsoft or its little elves slip in anything they want and call it good.

That's not all. According to Jomar Silva of Brazil, who attended the BRM and just received the secret report on progress on OOXML, several items that were supposed to be fixed are still not incorporated into the published text of the standard one year later, despite the fact that he says some voted a conditional Yes, contingent on those changes being made.

If you are considering whether or not to adopt IS29500, what should that tell you? That maybe you should wait until they get the kinks out?

I'd like to quote a bit from Silva's April 8 report:

Received in recent days several documents from JTC1/SC34 reporting the progress at the working group that is trying to fix the OpenXML, and it’s impressive and surreal what one may find in those documents.

The document N1101/N1168 contains for example, several items in which they recognize that there are decisions made in the BRM (BRM resolutions) which were not incorporated into the final published text of the standard. In other words, even taking almost a year after the a[p]proval of the standard to publish the text (yes, approved without reading), there wasn’t time/attention or anything else necessary to assure that the changes were published in the text (most of those changes, “conditioned” the approval). What makes me much more angry about this is that during the BRM I asked about who would be responsible for verifying that all these changes would be part of the final text and the answer was ITTF (kind of joint ISO/IEC secretariat). When I asked if the ITTF would really make this work, I received as a reply the intimidating: “You are doubting the ITTF, kid ?”…

On the document N1171, one of the working groups of SC34 announces that they’ve found problems in the OpenXML fonts specification and will submit an error report about it to the group responsible for repairing the standard (looks funny, but until today there are folks finding defects … ).

The document N1183 justifies the subdivision of the already existing parts of the standard to saying that to correct some errors pointed out, new “minor” features need to be added to the specification (and that is really cool, because now that the ISO has already approved the standard, they can write whatever they want, isn’t it?).

I saved the best for the end: document N1187. This one says that OpenXML “as is” contains unintentional errors that may prevent existing documents to be fully represented in this new format. It is amazing because the legacy support was alleged as the main reason for OpenXML development and approval at ISO, and also the reason why several countries supported the development and approval of the standard. In this document, they also explain the criteria that will be used to specify the changes that will be developed, so that they can do it all really quickly (in other words, they go trough the breaches of the JTC1 directives to get these changes incorporated into standard already approved without making much noise about it).

Brown's tweet was that same day. Had he also seen the report Silva writes about? In any case, he provides some more details on his blog about "fixing" changes made at the BRM:
The UK proposed an interesting new defect during the Prague meetings, which centred on one of the decisions made at the BRM.
Nature of the Defect:

As a result of changes made at the BRM, a number of existing Ecma-376 documents were unintentionally made invalid against the IS29500 transitional schema. It was strongly expressed as an opinion at the BRM by many countries that the transitional schema should accurately reflect the existing Ecma-376 documents.

However, at the BRM, the ST_OnOff type was changed from supporting 0, 1, On, Off, True, False to supporting only 0, 1, True, False (i.e. the xs:boolean type). Although this fits with the detail of the amendments made at the BRM, it is against the spirit of the desired changes for many countries, and we believe that due to time limitations at the BRM, this change was made without sufficient examination of the consequences, was made in error by the BRM (in which error the UK played a part), and should be fixed.

Solution Proposed by the Submitter

Change the ST_OnOff type to support 0, 1, On, Off, True and False in the Transitional schemas only.

The result of the BRM decision being addressed here was apparent in a blog entry I wrote last year, which attracted rather a lot of attention.

Simply put, the UK is now suggesting the BRM made a mistake here, and things should be rectified so that existing MS Office documents “snap back” into being in conformance with 29500 transitional.

This proposal caused some angst. Who were we (some asked) to overturn decisions made at the BRM? My own view is less cautious: this was an obvious blunder, the BRM got it wrong (as it did many things, I think). So let’s fix it.

So, a committee gets to change what the BRM as a full group decided? Says who? If Brown thinks the BRM got many things wrong, why was the result confirmed as it was, even when appeals were filed? And how many "wrong" things will Brown and his colleagues now try to "fix"?

I think the problem at the BRM wasn't that no one read the OOXML format first, but no one in charge listened or cared if it worked or not prior to being approved, even when national bodies tried to tell them there were problems. Remember the old Lily Tomlin routine? "We don't care. We don't have to. We're the phone company"? And now, the UK would like to fix what the BRM voted on, so that MS Office documents will conform to "29500 transitional". Love the name. Wait. Didn't Brown tell us that transitional was closer to Ecma 376? Why, yes. Yes, he did, a year or so ago, in the referenced article:

The TRANSITIONAL conformance model is quite a bit closer to the original Ecma 376. Countries at the BRM (rather more than Ecma, as it happened) were very keen to keep compatibilty with Ecma 376 and to preserve XML structures at which legacy Office features could be targetted. The expectation is therefore that an MS Office 2007 document should be pretty close to valid according to the TRANSITIONAL schema.
Keen but sloppy, I guess, and close but no cigar, because now we learn that they didn't fully keep compatibility with Ecma 376, let alone the so-called "strict" (explained here). Didn't the UK read before voting to approve OOXML? You think the BRM was too hasty, maybe? That it shoved through a half-baked format? Shouldn't a standard be, at a minimum, something you can, you know, actually use?

If you are a government or an agency considering OOXML and whether you should adopt it, might it be wise to wait until it's actually finished and fully operational, quite aside from the abysmal lack-of-real-interoperability-with-ODF issue? Shouldn't a standard at least work?

So, who gets to vote on this retroactive fix? Should they maybe get back to basics and just start over, take their time, and get it right? Brown bemoans the lack of progress on the interoperability front, but isn't that putting the cart before the horse? Interoperability with what? Here's the scary part, his solution to the slow progress in interoperability:

In my view, the only hope of achieving any meaningful harmonisation work is to get Another Big Vendor interested in backing it, and I know some behind-the-scenes work will be taking place to beat the undergrowth and see if just such a vendor can be found.

ODF's Approval

The entire Brown tweet about ODF and OOXML on April 8 goes like this, for the record:

@dmahugh ODA=white elephant;ODF=nobody read it before yessing, but maybe one day;OOXML=tought fights;revealed JTC 1 procedures were rubbish

5:59 AM Apr 8th from BeTwittered

al3xbrown
Alex Brown

Since Brown followed up with a complaint that Groklaw didn't reproduce his complete statement, I thought I would so now and respond. Let's compare.

For starters, it was the European Commission's Interchange of Data between Administrations Management Committee that urged OASIS in 2004 to submit ODF to ISO. Is Brown's flippant tweet not disrespecting that EU Commission committee, suggesting that its members failed to read ODF and mindlessly recommended its submission? I think we may assume that they read it carefully and liked what they saw. They were not alone, as I will demonstrate.

The National Archives of Australia not only read it, they helped to draft it and adopted it for the Archives. Microsoft joined the ODF Technical Committee. Is he saying Microsoft did not read it? Well, let's leave that in the Maybe column. If no one read it, why would membership in the ODF Alliance grow to 138 members in a month, which it did shortly before the ISO vote?

"In just a few weeks, there's been terrific momentum in support for the OpenDocument Format from across the globe," said Ken Wasch, the president of the Software & Information Industry Association and a member of the Alliance. "This diverse support grows everyday and ranges from the city of Bloomington, Indiana, and the National Archives of Australia to the Indian Institute of Technology and the Bristol City Council [United Kingdom]. All of our supporters know that ODF represents a better way for all governments to preserve, access and better control their documents," he said in a statement.

Speaking of reading and discussing, here's the OASIS message archives, where you can read all about just how detailed the discussion was at OASIS, and it was done in public, with anyone able to follow that discussion through the years. That's a refreshing policy, and it also makes it possible to deFUD the FUD, when folks make unsubstantiated claims. My point is this: how would Brown know who did or didn't follow those very detailed discussions? Obviously, he wouldn't. That's why I call it FUD.

As for ISO approval, here's the vote, reported on Andy Updegrove's Standards Blog May 03, 2006:

The vote passed with broad participation and no negative votes (there were a few abstentions), and ODF is now ISO/IEC 26300.
As you can see, it was unanimous, with "broad participation". If you've been following ODF as long as I have, you remember the detailed discussions and testing of ODF in Massachusetts, which made it an important topic as far back as early 2005. A lot of folks read it, as I think he must know. It was discussed at length and in detail. Papers were written on it. Public hearings were held. Here's Groklaw's ODF/OOXML permanent history of what happened. Dig in and see for yourself. Let me know about any broken links, please. Massachusetts keeps moving their documents around. I would too, if I had acted like Massachusetts, I would think. It's unseemly to say we told you so, but can't the new problems that just came to light about OOXML teach us something? Here's what I get out of it: if a large group of knowledgeable geeks tell you something technical won't work, and politicians and marketers tell you it will, you'd be wise to listen to the geeks.

If you'd like to know the latest, here's an article for you, an IEEE Internet Computing article on OpenDocument. More details on ODF here. As of February, 17 national and 8 provincial governments around the world have officially endorsed ODF for document exchange, with the UK doing so that month, according to this ODF Alliance press release [PDF]. RIM announced support for ODF in Blackberries too. And finally, here's Wikipedia's list of applications that support ODF, which leads me to the inevitable conclusion that even if Brown had been correct, it's clear a lot of folks have read ODF now and they love it and use it. Who is using the OOXML standard as "approved" at the BRM? No. Really. Have all the contingent approvals, based on promises to make certain changes, been accomplished? So is *anyone* able to use the BRM-approved "standard"? If not, on what basis would it be accurate to highlight ODF as any kind of issue? It's used, literally, all over the world. Can OOXML supporters like Mr. Brown say the same for that format?

Were the Appeals Against OOXML's Adoption Valid, Then, After All?

South Africa, in its appeal, said they were working too fast at the BRM:

In conclusion, South Africa challenges the validity of a final vote that we contend was based upon inadequate information resulting from a poorly conducted BRM. Moreover, we challenge the validity of a process that, from beginning to end, required all parties involved to analyze far too much information in far too little time, involved a BRM that did not remotely provide enough time to perform the appointed purpose of that procedure, and for which an arbitrary time limitation was imposed to discuss and resolve a significant number of substantial responses, despite the Directives not requiring any such limitation as to duration.

It is our opinion that the process followed during all stages of this fast track has harmed the reputations of both ISO and the IEC and brought the processes enshrined in the Directives into disrepute, and that this negative publicity has in turn also harmed the reputations of all member bodies of ISO and the IEC.

Brazil was specific, saying it was blocked from presenting a proposal about legacy binary mapping:
At the BRM, the Brazilian delegation was not allowed to present an important proposal regarding the legacy binary mapping. This proposal was a complementary part of USA delegation proposal regarding the new organization of the ISO/IEC DIS 29500. It also shall complement the scope change proposal approved at the BRM. Brazil has tried to present this proposal, during the debates, on the first day of the meeting and, attending to a request made by the convenor, Brazil has taken offline discussions with USA and other delegations and prepared its proposal to be presented on Friday, during USA proposal presentation.

On Friday, when USA ended their part of presentation and asked for Brazil to present its part of it, the convenor denied this opportunity to Brazilian delegation.

Several delegations has protested against that arbitrary decision, but those appeal was in vain and until the end of the BRM, the Brazilian delegation was not able to present its proposal. The main reason alleged by the convenor was "lack of time".

The proposal here mentioned, is the one available on the file "Br_Multipart_Proposal.ppt" available to all BRM members the ISO/IEC/JTC1/SC34 website at least since the fourth day of the meeting.

Brazil also noticed that most of the decisions taken during the BRM were based on the "lack of time" argument, and we think that this is completely incompatible with the kind of decisions that should have be taken on that meeting.

India correctly identified the problem in its appeal, one that has come back to haunt OOXML:
During the Ballot Resolution Meeting (BRM) on 25-29Feb 2008, a large number of modifications were decided to be made in the document. The whole document was restructured and scopes of different parts were modified.

As per 13.12 of JTC 1 directives it is stated that "In not more than one month after the ballot resolution group meeting the SC Secretariat shall distribute the final report of the meeting and final DIS text in case of acceptance." However, the final text incorporating the modifications, as envisaged in the BRM is not available even as on date, thus violating JTC 1 directive.

And Venezuela spoke similarly, even providing a chart of unresolved issues:
1- In our opinion, the procedures used during the discussions of DIS 29500, including the Ballot Resolution Meeting held from 25 to 29 February 2008 are incompatibles with basic principles to the standardization, such as consensus, technically oriented discussions and redundancy of standards, among others.

2- It is also our opinion that the proposed standard produced trough this procedures may be detrimental to the reputation of IEC or ISO as an standardization body, because of the clear absence of guidelines for the presentation of ISO standards.

3- We believe that the use of the fast track procedures was inadequate to the length and technical complexity of the DIS 29500 proposal, which added to the lack of technical, objective discussion, and the fact that procedures used during the Ballot Resolution Meeting held from 25 to 29 February 2008 leaved unattended too many standing technical issues in the proposal, resulted in a standard proposal that lacks the quality that usually describes the body of work of ISO....

Venezuela challenges the validity of a process that, from beginning to end, required all parties involved to analyze far too much information in far too little time, involved a BRM that by far did not provide enough time to perform the appointed purpose of that procedure, and for which an arbitrary time limitation was imposed to discuss and resolve a significant number of substantial responses, despite the Directives for not requiring any such [l]imitation as to duration.

If they were right, why were the appeals denied? I know the JTC1 folks don't care, but if you are thinking about adoption of ODF and/or OOXML, and you care about truly open standards, shouldn't you?

Update: Mr. Brown made a number of comments on this article, some so violative of our comments policy that they were removed. Many remain, and they struck me as being deliberately offensive, so as to get a rise out of Groklaw's readers. And sure enough, I see Mr. Brown tweeted the following on April 15 at 7:11 AM:

groklaw "a nasty little hate site"?
However, the plot flounders when Doug Mahue tweets in return:
today has been written off to groklaw bating
He links to one of his comments, without showing any context, but I've made a collection of his comments for you here and here.

So there you are. Now that they have admitted they were baiting us, you can study how they act and then in the future, you'll recognize the pattern. Please keep in mind when folks like this appear that they are deliberately trying to bait us, so you and I will say things they can then pretend they think is hateful. Blech. Like high school hijinks, but with a snitch element. While we were sincere, they were cynics. I despise such conduct of course, and I guess I thought men in their positions would act in a more mature way, but whatever.


  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 )