As those who are following Microsoft's OOXML formats through the standardization process will know, those formats (now officially known as Ecma 376, following the favorable adoption vote in Ecma on December 7 of last year) are now in the "contradiction" phase in JTC 1 at ISO/IEC. Or, so it would seem, they are in the "so, what is a contradiction, anyway?" phase.
Microsoft has won the first point in this match (on which more below), as national bodies around the world wrestle with this question. But first, some context on what's going on, and why it matters.
The question of what a "contradiction" may be under the ISO/IEC rules is of more than passing interest. On the most basic level, the question is legitimate, since ISO/IEC apparently do not supply a precise definition, even though one out of the six months in the ISO/IEC Fast Track process is allocated to the submission of contradictions by the 60-odd Principal and Observer members of these global standards organizations that are entitled to respond during this phase.
How does a national body submit what one must first define? And why should ISO/IEC ask its members to submit contractions until ISO/IEC has taken the trouble to define what they are? Or perhaps ISO/IEC in fact have provided adequate guidance, and the battle between ODF and OOXML has simply escalated to the point where anything and everything will be taken to the barricades, regardless?
The answer to that last question, it appears, is "yes - regardless."
The fact is that debates are not only raging (as debates are wont to wage) across the Web on that precise question, but in the national bodies as well. Microsoft, not surprisingly, is arguing that a contradiction should be defined very narrowly. This is how Microsoft's Office manager Brian Jones teed it up at his Open XML Formats blog a few days ago:
[The Contradiction Period]…is where you want to make sure that the approval of this ISO spec won't cause another ISO standard to break. In the case of OpenXML, there really can't be a contradiction because it's always possible to implement OpenXML alongside other technologies. For instance, OpenOffice will soon have support for ODF and OpenXML.
An example of a contradiction would be if there was a standard for wireless technology that required the use of a certain frequency. If by using that frequency you would interfere with folks using another standard that also leverages that frequency, then there may be a contradiction.
Meanwhile, Rick Jelliffe, of recent Wikipedia fame, seems to be singing from the same hymnal when he blogs as follows at O'Reilly XML.com (the following are only excerpts from this entry):
I take a fairly strict view of “contradiction”. Anything else works against fairness of process.
A contradiction is where
- One standard attempts to redefine another, or is a rival standard for exactly the same named thing but is different in some aspect. The precedent here is the contradictions alleged between two standards for UNIX-derived APIs that arrived at ISO by different routes ">ISO Linux API and ISO POSIX. The remedy is withdrawal and harmonization.
- One standard disrupts another....
- One standard pretends to be another. The precedent for this at ISO are the UK objections to C++/CLI. The remedy for this is a simple name change, and other associated editorial changes.
- One standard incorrectly uses another. For example, if a standard said it used ISO SGML but allowed that to be invalid for no intrinsic reason. (I have not found any precedent for this, but it seems the obvious case.)
A contradiction may have negative effects, such as user confusion, but it is not the negative effects that cause that there is a contradiction; a highly technical standard will confuse anyone. It is the direct contradictions int he text of the standards that is involved.
So what, in those terms, are not contradictions?
- Overlap. There are many overlapping standards....
But isn't the question of the hour what ISO/IEC says a contradiction is, rather than what one outsider or another thinks the word should mean?
Marbux, in contrast, points out this guidance from JTC1 literature, as posted in his blog at the OpenDocument Fellowship site:
JTC 1 stresses the strong need for consistency of its products (ISs and TRs) irrespective of the route through which they were developed. Any inconsistency will confuse users of JTC 1 standards and, hence, jeopardize JTC 1's reputation. Therefore, referring to clauses 13.2 (Fast Track) and 18.104.22.168 (PAS) of its Directives, JTC 1 reminds ITTF of its obligation to ascertain that a proposed DIS contains no evident contradiction with other ISO/IEC standards. JTC 1 offers any help to ITTF in such undertaking. However, should an inconsistency be detected at any point in the ratification process, JTC 1 together with ITTF will take immediate action to cure the problem.
To which he adds the following, from the World Trade Organization's Agreement on Technical Barriers to Trade Annex 3(H), Code of Good Practice for the Preparation, Adoption and Application of Standards states:
The standardizing body within the territory of a Member shall make every effort to avoid duplication of, or overlap with, the work of other standardizing bodies in the national territory or with the work of relevant international or regional standardizing bodies.
The last point is certainly relevant to the overall process, although one could not tell with certainty whether it bears upon the first month (contradictions), or the next five (voting and other objections). It is at least the latter, since during the five month JTC 1 voting phase, c. 157 countries will be entitled to voice their opinions on Ecma 376, due to the impact of the WTO rules.
All that being said, you may ask, why bother to spill so many words over this hair splitting at all?
Here's why. The most persuasive comments (and contradictions) come from the national bodies that ultimately have the power to vote up or down on an ISO/IEC proposed standard. In the United States, the national body empowered to exercise this right is the American National Standards Institute (ANSI). For document formats, the ANSI member organization to which ANSI delegates responsibility for crafting the US response is the International Committee for Information Technology Standards, more commonly referred to simply as "INCITS."
Yesterday, I learned that the Executive Board of INCITS decided earlier in the day not to propose to ANSI that any contradictions need be identified between OOXML and any ISO/IEC standards, Directives or other rules. The reason is that Microsoft, which has a member on the committee, has persuaded a sufficient number of members of the INCITS Executive Board to adopt a very conservative definition for a "contradiction" – that definition being essentially the one articulated by Brian Jones at his blog – that a contradiction arises only where a system could not run two products, each of which implements one of the two specifications in question.
The alternative suggestion made by others on the INCITS Executive Board had been to present all perceived contradictions to INCITS, accompanied by an explanation that there was a division over whether a narrow or a broad definition of contradictions was appropriate. This would have allowed the managers of the process at JTC 1 to decide what to record as a contradiction, and what to disregard. Unfortunately, sometime between Monday and Tuesday of this week, the consensus behind that course of action evaporated, and the narrow view carried the day. The US formally sees no contradictions.
Is that what INCITS should have concluded? Quite a few people thought otherwise, as you can see from the comments received by INCITS from members and non-members.
Happily, INCITS will forward all of the comments received to the full committee that will decide how to vote on OOXM. Much of this input was produced as a result of a heroic effort by Groklaw's Pamela Jones and her volunteers, who set up two very impressive pages at Groklaw, in Wiki format. The first allows interested parties to find and log in contradictions and objections, while the second tracks the ISO/IEC process. Pamela's own detailed writeup can be found here.
All of which raises the question of whether the effort to limit the number of issues that are formally identified as "contradictions" will prove to be tactically smart or ultimately foolish.
Given that all of this input is public, and can be taken into account in the ultimate voting, it strikes me as foolish for Microsoft to seek to limit what JTC 1 will receive during the contradiction period. When issues exist, I believe that they are better confronted than ignored. If in fact the right conclusion proves to be that Microsoft was correct, then that conclusion can be reached and announced by JTC 1, rather than presupposed by a small group of INCITS representatives.
People that have strong feelings and take the time to express them would always prefer to be heard. Sitting on that that input, rather than forwarding it to JTC 1, seems to me like a poor decision on the part of our national representatives. And perhaps it is even bad strategy for Microsoft, as those that wished to be heard will be incented to press their opinions all the more forcefully during the voting phase.
Better that a standards adoption process should concern itself with the quality of a proposal, I think, than with how many contradictions can dance on the head of a pin.
For further blog entries on ODF, click here
For further blog entries on ODF, click here