Once more Patrick Durusau (below) reflects on the Open XML ballot, separating facts from fiction and concluding that whatever you might feel about the process and remaining shortcoming of Open XML, SC34 is the obvious and only real place to fix those issues going forward. I agree.
A couple of times people have come up to me and suggested that ratifying Open XML is like giving it an A+, which they implicitly do not feel it is worthy of. Obvious such utterance shows a lack of understanding about what standardization really is. The ISO process is not an exam and ratification is by no means the last step in a process, rather it is the beginning of a journey. Why someone would prevent this journey to begin is beyond me, especially when considering the huge amount of work that have gone into Open XML over the past almost 18 months.
During the DIS29500 ballot the Open XML specification have been scrutinized to an extend rarely, if ever, seen in any former similar process. Thousands and thousands of hours have been spent by people around to globe to identify issues with the specification as well as to correct those issues. Why should we not recognize this work done by these people? Why should we not let this work continue to be carried out in the international settings of ISO/IEC?
A lot of doubts and uncertainty have been raised by the anti-Open XML coalition , but nobody have managed to give a real answer about what the actual benefits are suppose to be by excluding Open XML from international standardization. Excluding Open XML from ISO/IEC is excluding the international community from having a direct saying on the further development of Open XML and its future. What is the sense of that? The ODF Editor, Patrick Durusau, addresses this very question in his open letter Who Loses If Open XML Loses.
Ad Hoc Rules, Process Failures and OpenXML
The last minute arguments against OpenXML appear to be shaping up to be: a lack of full considerationof all comments at the BRM, no final text for approval, and errors remain in OpenXML. What haspuzzled me is the response by some that attempt to dispute the factual basis for these charges.
I say that because I think it is beyond dispute that not all comments were adequately considered at theBRM, there is no final text for approval and I have no personal doubt that errors remain in OpenXML. However, responsibility for all of those unhappy facts do not lie with OpenXML.
Let's start with the lack of adequate consideration of all comments at the BRM. I have searched the JTC1 Directives can can report there is no five-day limit on a ballot resolution meetings anywhere in those Directives. Moreover, the norm is to have multiple BRM meetings ntil all comments have been fully considered. The responsibility for the five day ballot resolution meeting process failure lies with someone other than OpenXML.
There is no final text for review prior to voting. True, and it is also true that the ad hoc rules in place were not written by OpenXML. Moreover, even if a final text were available, there would not be adequate time to review it. It seems churlish at the very least to condemn a proposal for the failure of ad hoc rules developed by others.
Finally, the old saw that errors remain in OpenXML. Well, I was reading the second edition of the HyTime standard recently and noticed an error in the text. That text was approved in 1997. So yes, there still errors in OpenXML. The question is: Are they significant enough to prevent it from being an ISO standard? That is the question where the anti-OpenXML forces fail and why they worry about vague and unspecified errors.
I don't think that OpenXML should be penalized for ad hoc rules/process failures that are entirely the responsibility of others. Whatever the current shortcomings of OpenXML, SC 34 is the proper place to repair it [my bold].
Covington, 26 March 2008
Patrick Durusau