"Yes with comments" for Open XML

  • Article

Germany just announced that their vote for Open XML will be “YES with comments”. The INCITS Executive Board in the US has approved a ballot for consideration that is “YES with comments“ and a vote will be taken for this on August 22. Yet, there is an ongoing question from folks in the community as to whether or not “YES with comments“ is a viable vote if those comments are to be considered in both the ballot resolution and long-term maintenance process for a standard. This question ties into the complexity of how specifications get created, what the rules are that govern their consideration, and what commitments are made by organizations and individuals involved with their maintenance. Here is why “Yes with comments” is a valid vote:

  1. The Rules: Before looking at any other factor, it is absolutely within the scope of JTC 1 rules for organizations to cast a YES vote and to add technical and other comments to that vote. Comments may be added to YES, NO, or ABSTAIN votes. If a national body casts a NO vote, they must provide comments with the vote. But, that is not the only way comments get considered. The whole point of the ballot resolution process is that comments get considered and responded to for all comments, which will then be considered by the national bodies. At the end of the process, they have a period of time to revisit their position and communicate a revised vote to JTC 1. The argument that a NB has no leverage in the BRM process if they vote YES is simply not true. 
  2. Precedent: YES with comments is an established practice with national bodies. A small amount of research shows that INCITS, the arm of the US national body that handles all JTC 1 technical matters, has submitted 22 “YES with comments“ votes in the past 4 years – including specs developed at Ecma International, and OSS-related specs such as the Linux Standards Base Core Specification 2.0.1.
  3. Maintenance Commitment: As I have blogged about recently, Ecma has made a clear statement that they are committed to considering ALL comments in the analysis document they will prepare for discussion at the expected Ballot Resolution Meeting. Ecma’s TC45 will be meeting frequently to prepare their analysis after the aggregated comment list is distributed to all voting National Bodies.
  4. Specs are not perfect: Technical specifications are never perfect – they always may be improved. This is the whole reason there is a maintenance plan requirement when specs are submitted for consideration in either the PAS or Fast-Track process. Both PAS and Fast-Track submissions are initially balloted as a proposed DIS (draft international standard) which means significant work was done by a qualified working group or technical committee, and the process and engineering meet the ISO/IEC requirements for PAS or Fast-Track status. But – it also means that the DIS (rather than the WD or CD forms in the case of the full process) is the first formal view of the spec given to a national body. Therefore, unlike the 30 or 45 day norm for timeframe of consideration of a spec at the industry consortia level – the national bodies have a 5-6 month voting period, plus another 3-6 months prior to the BRM, to consider the Fast-Track or PAS DIS. (Just to be clear, ODF 1.0 went through JTC 1 as a spec that clearly needed significant technical improvement as can be seen by the ongoing work from OASIS.)

Aside from these procedural-related elements, there are some big picture considerations for Open XML specifically.

  • Direct Requests For Standardization: Detractors of Open XML often downplay or ignore the fact that the impetus behind the standardization of Open XML in no small part came from governments who felt it was in their best interest to have the Microsoft default XML format used in the Office product be standardized and for the broadest international community to have an ongoing voice in its evolution. Good examples of this are the European IDABC in their Valoris report of 2003, TAC recommendations of 2004, and the PEGSCO recommendations of 2006. Voting YES on Open XML affirms these findings, and the comments (in light of the 4 points above) enable them to express their desire for technical issues to be considered. The BRM process and the commitment from the Ecma TC combine to provide the national bodies with a robust vehicle for technical concerns to be reviewed to address perceived issues.
  • Greater Openness and Choice Is The Goal: It is in the best interest of national governments to aggressively encourage openness in document formats. Interoperability, choice of commercial solutions, competitive opportunity for local software producers, long-term archival – these are a few of the goals of which everyone is supportive. But, this does not mean only one format. Governments want to see innovation, they want technology to progress rapidly and with the maximum opportunity for all parties (level playing field) and choice. Innovation tends to be more about the apps than the formats, but the formats should not become a blocker to the innovation of the app. Nor should innovation around interoperability be limited to standardized components. Voting NO for Open XML, in my most humble opinion, is a vote against greater document openness. 
  • Independent Implementations: In the 9 months since Open XML was standardized at Ecma, there are already significant independent implementations which demonstrates that the spec is absolutely mature enough for real commercial use. Standards organizations, including JTC 1, do care about market relevance of their approved specifications. Given the multiple, independent implementations of the Open XML specification that includes diverse platforms (iPhone, Palm OS, Windows, Mac, Linux) and a broad spectrum of applications, it is clear that the Open XML spec is mature enough, and sufficiently sound from both a technical and legal perspective for implementation. Again, if ISO/IEC ODF version 1.0 is the yardstick to measure Open XML in terms of spec readiness – then there is no question that a YES vote is reasonable. As I stated above, the spec is not perfect and many of the comments included with the votes can improve the specification.