An Antic Disposition

We typically use words to communicate, to be understood. That is the common case, but not the only case. In some situations, words are used like metes and bounds to carefully circumscribe a concept by the use of language, in anticipation of another party attempting a breach. This is familiar in legislative and other legal contexts. Your concept is, "I want to lease my summer home and not get screwed," and your attorney translates that into 20 pages of detailed conditions. You can be loose with your language, so long as your lawyer is not.

But even among professionals, the attack/defense of language continues. One party writes the tax code, and another party tries to find the loopholes. Iteration of this process leads to more complex tax codes and more complex tax shelters. The extreme verbosity (to a layperson) of legislation, patent claims or insurance policies results from centuries of cumulative knowledge which has taught the drafters of these instruments the importance of writing defensively. The language of your insurance policy is not there for your understanding. Its purpose is to be unassailable.

This "war of the words" has been going on for thousands of years. Plato, teaching in the Akademia grove, defined Man as "a biped, without feathers." This was answered by the original smart-ass, Diogenes of Sinope, aka Diogenes the Cynic, who showed up shortly after with a plucked chicken, saying, "Here is Plato's Man." Plato's definition was soon updated to include an additional restriction, "with broad, flat nails." That is how the game is played.

In a similar way Microsoft has handed us all a plucked chicken in the form of OOXML, saying, "Here is your open standard." We can, like Plato, all have a good laugh at what they gave us, but we should also make sure that we iterate on the definition of "open standard" to preserve the concept and the benefits that we intend. A plucked chicken does not magically become a man simply because it passes a loose definition. We do not need to accept it as such. It is still a plucked chicken.

(This reminds me of the story told of Abraham Lincoln, when asked, "How many legs does a dog have if you call the tail a leg?" Lincoln responded, "Four. Calling a tail a leg does not make it a leg.")

With the recent announcement here in Massachusetts that the ETRM 4.0 reference architecture will include OOXML as an "open standard" we have another opportunity to look at the loopholes that current definitions allow, and ask ourselves whether these make sense.

The process for recommending a standard in ETRM 4.0 is defined by the following flowchart:



So, let's go through the first three questions that presumably have already been asked and answered affirmatively in Massachusetts, to see if they conform to the facts as we know them.

1. Is the standard fully documented and publicly available? Can we really say that the standard is "fully documented" when the ISO review in the US and in other countries is turning up hundreds of problems that are pointing out that the standard is incomplete, inconsistent and even incorrect? We should not confuse length with information content. Just as a child can be overweight and malrnourished at the same time, a standard can be 6,000 pages long and still not be "fully documented." Of course, we could just say, "A standard fully documents the provisions that it documents" and leave it at that. But such a tautological interpretation benefits no one in Massachusetts. We should consider the concept of enablement as we do when prosecuting patent applications. If a standard does not define a feature such that a "person having ordinary skill in the art" (PHOSITA) can "make and use" the technology described by the standard without "undue experimentation" then we cannot say that it is "fully documented." By this definition, OOXML has huge gaps.
   
2. Is the standard developed and maintained in a process that is open, transparent and collaborative? We're talking about Ecma here. How can their process be called transparent when they do not publicly list the names of their members or attendance at their meetings, do not have public archives of their meeting minutes, their discussion list or document archive, do not make publicly available their own spreadsheet of known flaws in the OOXML specification nor of the public comments they received during their public review period? How is this, by any definition, considered "transparent"? We can also question whether the process was open. When the charter constrains the committee from making changes that would be adverse to a single vendor's interests, it really doesn't matter what the composition of the committee is. The committee's hands are already tied and should not be considered "open." If I were writing a definition of an open, transparent process, I'd be sure to patch those two loopholes.
3. Is the standard developed, approved and maintained by a Standards Body? Without further qualifying "Standards Body" this is a toothless statement. As should be apparent right now, not all SDO's are created equal. Some of the standards equivalent of diploma mills. Accreditation is the way we usually solve this kind of problem. Ecma's Class A Liaison status with JTC1 is not an accreditation since their liaison status has no formal requirements other than expressing interesting in the technical agenda of JTC1. In comparison, OASIS needed to satisfy a detailed list of organizational, process, IPR and quality criteria before their acceptence as a PAS Submitter to JTC1/SC34. Why bother having a requirement for a Standards Body unless you have language that ensures that it is not a puppet without quality control?
   
4. Is there existing or growing industry support around the use of the standard? Again, very vague. A look at Google hits for OOXML documents shows that there are very few actually in use. My numbers show that only 1 in 10,000 new office documents are in OOXML format. But I guess that is more than 0 in 10,000 that existing last year. But is this really evidence for "growing industry support"? I'd change the language to require that there be several independent, substantially full implementations.
   

There are two additional questions which I won't presume to answer since they rely more on integration with internal ITD processes.

We learn lessons and move on to the next battle. Just as GPLv2 required GPLv3 to patch perceived vulnerabilities, we'll all have much work to do cleaning up after OOXML. Certainly JTC1 Directives around Fast Tracks will need to be gutted and rewritten. Also, the vague and contradictory ballot rules in JTC1, and the non-existent Ballot Resolution Meeting procedures will need to be addressed. I suggest that ITD take another look at their flowchart as well, and try to figure out how they can avoid getting another plucked chicken in the future.

Labels: Ecma, OOXML, Standards

This is taken from slide 21 of Ecma's "Standards @ Internet Speed" presentation (22 June 2007 version) which you can download here. It appears to be a sales pitch.

I've joked about the Ecma process before, but I never thought I'd see it written out officially like this. Standards are made available "on time"? Minimize the "risk" of changes? I thought the whole purpose of technical review was to find the problems and fix them? As always, the man who pays the piper calls the tune.

(Also, you gotta love the "wink and nod" approach to patents on slide 16, where they can pretend a problem doesn't exist if one member disputes that a patent is essential to implement the standard.)

Labels: Ecma, OOXML

I work in a house with glass walls. Not literally, of course. The cost to air-condition such a house would be prohibitive. I mean that working on standard in OASIS is a public act, with process transparency and public visibility. The public doesn't see merely the end-product, or quarterly drafts, they can see (if they are so inclined) every discussion, every disagreement and every decision made by the TC, in near real-time. Our meeting minutes for our TC calls are posted for public inspection. Our mailing list archives, where most of the real work occurs, is there for the public to view. The comments submitted by the public are also available for anyone to read. This information is all archived from when the TC first met back in 2002, all the way to the discussions we're having today on spreadsheet formula namespaces.

One result of this openness is that it is very easy, trivial even, for our critics to simply read our mailing list, look for a disagreement or discussion of an issue, and repeat our words, usually out of context. Cut & Paste. This is certainly the most efficient way to criticize ODF since it minimizes the amount of thinking required. However, this is a bit tedious, especially when this is applied so asymmetrically, as I shall now explain.

Ecma TC45, the committee producing Office Open XML (OOXML), does not operate in such a transparent manner. They do not have a public mailing list archive. They have not published their meeting minutes. The comments they receive from the public are not open for the public to read. The public has no idea what exactly the TC is working on, what issues they think are critical, whether the TC is in unanimous agreement, whether there is spirited debated or whether Microsoft dominates and determines everything. The fact that they have not yet sent OOXML for an Ecma vote is proof that believe the specification is not yet ready for standardization. But we know no details of what exactly is lacking, what problems are being fixed or, more importantly, what defects are being allowed to remain.

And in this way, the ODF-bashers take advantage of our openness, while holding their deliberations in obscurity. They throw rocks at our glass house while hiding in the shadows.

So this openness at OASIS has an apparent downside. But honestly, I wouldn't trade it for any alternative. Making a standard, especially one this important, is a privilege, not a right. The public deserves to know how a standard is made, the same way and for the same reasons they deserve to know how legislation is made. I relish this scrutiny because I know it makes us stronger.

Sun's Simon Phipps has posted his keynote from the recent OSCON conference. The topic was the “Zen of Free” and, among other goodies, Phipps lists 5 requirements for “full support for fully open standards”, of which I quote the 4th, since it states the point better than I have:

…the standard [Phipps here speaking generically and not about any specific standard] should have been created transparently. Just as an open source community looks with concern on a large, monolithic code contribution, so we should be wary of standards created without the opportunity for everyone to participate or, failing that, with a full explanation of every decision that was made in its construction. Without that there's a chance that it's designed to mesh with some facility or product that will be used to remove our freedom later.

Another way to attack openness is to do it with legal restrictions. For example, we're seeing many references to a year-old performance evaluation of an atypical spreadsheet file, and using that to make the ridiculous claim that the ODF format itself is too slow. I'd love to dispute that claim and show it for what it is. I'd love to show that for most common document sizes, ODF documents are actually smaller and faster to load and save than OOXML documents. I'd love to show you all this, but I can't. Why? Because Microsoft won't let me. The only implementation of OOXML is the Office 2007 beta, and the End User License Agreement (EULA) has this language:

7. SCOPE OF LICENSE. …You may not disclose the results of any benchmark tests of the software to any third party without Microsoft’s prior written approval

So, our critics can quote benchmark results about ODF running in OpenOffice, but we can't quote numbers about OOXML running in Office. They can read our mailing lists and quote us discussing ODF issues as we address them, but we cannot even see what they are working on.

What should we make of all this? I suggest that no specification is perfect. That's why we have version numbers. The question you need to ask yourself is: what leads to a better specification, full and open public discussion and scrutiny? Or something rushed through behind closed doors? You know what the issues with ODF are, and you'll continue to hear the same small list over and over again. But this is a shrinking list, as the ODF TC experts address these issues. But do you know what the issues with OOXML are, the reasons why Ecma TC45 has not yet put forward their specification as an Ecma standard? What do their experts say when speaking candidly about their specification? The public simply doesn't not know. Do we assume silence means perfection? I don't think so.

Labels: Ecma, OASIS, ODF, OOXML