Open XML BRM - A Response To Bob Sutor's Assertions
On November 15, Bob Sutor over at IBM posted an opinion on the ballot resolution meeting that I think is fundamentally misleading, but also raises some valid questions deserving consideration by all parties. To be clear, I think countries who voted no should carefully consider the technical work done leading up to the BRM and will hopefully move their votes to "yes." Obviously, Bob takes a different point of view.
The posting will be organized by my paraphrasing points made by Bob (in black text) and my responses to them (in blue text).
The BRM will result in a changed specification - those changes may themselves result in new problems.
Section 13 of the JTC 1 Directives discusses the BRM and make it clear that the whole point of the BRM is to change the specification in the interests of improving it and driving greater consensus for adoption. That is the point of the comments that are submitted, that is the point of having an Editor, that is the point of all the technical deliberations. In fact, IBM (whom Bob is representing in this discussion) was so good as to dedicate more than a year of work in reviewing the spec and submitting comments with recommended changes. It would seem inconsistent to now say that the disposition of comments somehow runs counter to the goal of having a quality specification or to cast a negative spin on these comments.
I know that the Project Editor is being very conscientious about the quality of the technical work done in the dispositions. The work of the Editor and TC45 is to improve the existing specification, not make a new specification. Clearly, the dispositions should be considered carefully by all parties. Yet, all parties should be interested in seeing an improved specification. (That was, after all, Rob Weir's justification for submitting so many comments - apparently IBM wants it both ways.)
The specification is long, there are thousands of comments, there is no way for a national body to consider the dispositions in the time they have.
IBM (read Bob) does not want you to notice that at the time of the Open XML (DIS 29500) vote last September, 87 national bodies had spent 5 months preparing comments - and most submitted proopsed dispositions to resolve their comments, as prescribed by the JTC 1 process. By the time of the BRM there will have been an additional 6 months of technical discussion/review and in total, more than a year of consideration of Open XML by national bodies since the DIS was submitted to JTC 1. More than that, there was another year of work done on the specification in Ecma TC45 and its submission to the Ecma plenary (where IBM chose not to join the TC and had the opportunity to review the spec for the plenary, and was the only Ecma participant to vote against in the plenary).
More importantly, there are waves of dispositions (comments and responses) being released for NB consideration in the months ahead of the ballot resolution meeting. This is coupled with the fact that the Project Editor is actively engaged in conversations with implementers and NBs around the world so that the dispositions are discussed in a professional manner in accordance with JTC1 Directives.
I do agree with Bob that the size and scope of the work is a serious engineering undertaking, and one that highly qualified people are working on - including IBM's own engineers and paid consultants (who are most certainly diligently working through the comments in order to block the spec - a highly unusual JTC1 practice, but that is for another time).
There are questions about the BRM process, attendance, time to consider all comments etc. - the process is bad.
Before you go too far on anyone else's blog - read this - it is the FAQ from the BRM convener. There is no process irregularity involved with the BRM whatsoever. IBM wants it both ways in Bob's argument. First, saying the process is broken, and then later saying that the process should be kept pure.
Some key points about the BRM:
- The BRM is NOT another vote - it is an opportunity for comments to be addressed, considered, and changes made to the spec by the Editor with the intent of improving the specification.
- NBs may reconsider their position on the specification within the 30 days following the BRM and may - if they choose - change their vote.
- BRM will be 5 days, held at the end of February
- BRM will be limited to the number of seats available (120 is the number stated)
- NBs who voted "no" are highly encouraged to attend
- The size of a NB delegation will be limited due to overall space availability - but the NBs may petition for the number of seats they would like to fill
The last item under this section is one that Bob raises that is worth considering. How will the BRM possibly move through 3000+ comments and dispositions in just 5 days. First, this is a technical discussion driven by engineers - a breed of people particularly adept at dealing with problems like this. The Editor is grouping comments and organizing them in a way that makes sense. Remember, IBM submitted most of the comments in most of the countries anyway - so a significant percentage of the comments are similar if not the same. That said, professional standards work by the Editor and TC45 (and the Convener) will make sure that all parties recognize that their issues were considered and included in the disposition. The 5 days will be structured to be productive and, hopefully, conclusive. I would hope that IBM is not planning to purposely derail conversations in order to create a process failure. That would be unseemly, no?
If you are not satisfied for any reason, vote against Open XML. The specification should be perfect or you should reject it.
This is a rather broad claim, and useful if you are seeking to block the adoption of the spec. But, it happens to be contrary to not only normal JTC1 practices, but it is completely out of line with IBMs own experience on ODF.
Specifications in standards are not perfect. I'll repeat that so that I'm clear. Specifications in standards are not perfect. In fact, they are expected to be living documents that improve over time. This way, they are applicable to implementers and are able to mature as technologies do. Otherwise, you would have a whole bunch of obsolete specs being approved and never used.
Let's take ODF for example. ISO/IEC IS26300 (ODF 1.0 released from OASIS in May 2005) is no longer a valid specification for the market. OASIS has been significantly adding functionality to that specification and has since gone to version 1.1 and now 1.2, and is now working on 1.3. Hmmmm. So, was ODF really too immature for international standardization when it went through? Shouldn't it now be submitted as either an "amendment" (the JTC 1 term for a major revision to an international standard) or a whole new spec? My point is, ODF is a living document that is improving as IBM and others continue to invest in it. Ok - I have no problem with that. But, this makes the point that there are elements to any spec that goes through the JTC1 process that are not perfect, and need improvement. Those elements DO NOT mean that the spec should be rejected out of hand. Thus, you have both comments and a BRM process to resolve them.
Don't set a bad precedent with this specification.
Open XML has received more scrutiny and dedicated engineering attention than any specification in JTC1 (if not ISO or IEC) history. The Ecma specification that is the basis for the Draft International Standard is seeing broad adoption with multiple independent implementations. The implementers are saying that the specification is incredibly well documented and enabling them to build quality, viable solutions that are solving customer needs while opening new revenue opportunities for them.
Rather than the War and Peace analogy that Bob references, it might be better to harken back to OSI and TCP/IP as the analogy. It is worth recalling that the IBM-promoted OSI specification was NOT broadly adopted, while the market-driven adoption of TCP/IP won out.
Ok - back to all black text:
This blog is not about me and Bob, it is about IBM and Microsoft having differing views on the BRM - so let's keep the comments focused on the substantive issues rather than about the people (thx). I agree with Bob that the sheer volume of technical work around Open XML heading into the BRM is daunting. But it is not insurmountable, and it is being handled in a professional and thorough manner. All parties involved should be pleased with the amount of work going into making this specification better. The irony here, to me, is that Open XML is already better because of this with or without the ISO imprimatur. It will be a more formidable competitor in the marketplace from all the help IBM has given it. Rather thoughtful of them I'd say.
It is going to be an interesting few months leading into February.