1. OOXML Ballot Resolution Meeting: Questions and Answers

Print Friendly

Geneva logo
Though I’ve written about this before, I continue to be amazed that there does not seem to be a single, unambiguous, and logically complete description of what will happen at the OOXML Ballot Resolution Meeting (BRM) in Geneva at the end of February. This is by no means a reflection on the convenor Alex Brown. Rather, for an organization like the ISO which is known globally for its standards relating to processes around quality, this situation is surprising, to say the least. That it needs reform is obvious, at least to me.

With this entry I’m going to start doing a series of pieces that I hope will help refine what we know and don’t know. I’ll state some things that I believe are true, on the advice of experts, and ask questions so that folks like Alex can answer and correct me. I’ll get more focused on the various subprocesses as we go, so this initial entry will be quite general. I will correct the pieces as we proceed.

If you are a member of a national standards body and have questions, feel free to add comments in this and other entries and I try to get them answered.

  1. Only those countries who voted in the September 2 ballot will be allowed to send delegations to attend the BRM in Geneva. By “attend,” I mean participate in the BRM meeting in the room that has been allocated for it. That room only holds between 120 and 130 people, so if all 87 countries who voted plan to attend, there will be some interesting problems of who gets to go. Other people may go and hang out in Geneva (bring your ice skates), but the official participating delegations will be limited. From what I’ve heard, many countries are planning to attend, but they will not have any guidance until December on how many can participate in the meeting itself.
  2. Delegations need to decide now how they will reach decisions in Geneva. It is very possible for delegations to deadlock on the resolution of comments at the meeting itself. The head of the delegation will be key, but accountability, transparency, and fairness will be paramount.
  3. Delegations need to decide now how they will pay for the costs of traveling to the meeting. Rest assured that this will be tightly scrutinized. That is, I expect the international community will demand a full accounting of who paid for what and exactly what the relationship is to the delegate. We wouldn’t want any accusations of an international standard being bought, would we? Remember, one of the main principles of openness is transparency.
  4. While at the BRM meeting, a delegation can very much care about the resolution of comments that they did not submit. That is, if you submitted 100 comments but you realize that the other 900 or so are important to you, you can hold out for a good resolution to all of them. Do not be convinced by anyone that you are limited in any way to worrying only about the comments that you yourself submitted.
  5. Consensus is supposed to be used in reaching agreements, but where this cannot be reached, a majority vote of the P members participating will be used as the voting procedure. I expect that all votes will be made publicly available. Thus the voting behavior of P members will be scrutinized especially in light of recent failures of JTC1 ballots.
  6. The matter of the success of OOXML will not be finalized in Geneva. I expect many national standards bodies will want to return home and debate the issues within the larger committees. They have 30 days to petition ISO and change their September 2 vote. This is also true for countries that do not attend the Geneva meeting. The Geneva meeting will only decide on what is essentially a new document: the original specification plus the proposed changes. If Microsoft proposes a resolution, make sure you get a guarantee that they will implement it.
  7. This is critical: in no situation should it be an allowable resolution for Microsoft or ECMA to say “we’ll fix that in a future version of the specification.” Either it gets resolved at the BRM or it doesn’t. Future promises mean nothing and are no guarantee of change. If it is not resolved and you care about it, it constitutes failure if only a promise of correction is offered.

What do you want to know about the BRM?

Also See: 2. OOXML Ballot Resolution Meeting: Why You Should Worry About All Comments


  1. No questions, just figured I’d say I appreciate you laying this all out and look forward to upcoming posts on the matter.

  2. [quote]This is critical: in no situation should it be an allowable resolution for Microsoft or ECMA to say “we’ll fix that in a future version of the specification.” Either it gets resolved at the BRM or it doesn’t[/quote]

    It might not be a resolution for an issue but it is allowable for Ecma to state that certain thing will only be considered in a future version and for national bodies to accept or reject that in the reconsidiration of their vote.
    A commitment on resolving an issue in the future will of course not count as a resolved issue but is is already evident that certain issues will not be resolved so certain national bodies will always have to decide on their vote with some issues left that will either not be resolved or accept that those might be resolved in a future version. There is no requirement to for all comments to be solved. The goal of the meeting is to compromise on resolving as may issues as possible and then the national bodies can decide whether or not to change their votes.

    However if national bodies accept such a commitment it is out of control of ISO as it has no official status. National bodies would have to trust Ecma en their own influence on the proces in SC34 when a new version is submitted.

  3. hAl: My advice still stands: if you expect something to be fixed, make sure it is fixed at the BRM. Otherwise, you need to accept that it might never change.

  4. I’m still not entirely sure what ISO are attempting to achieve by rubber-stamping (or not) a single-vendor standard.

    There have been times in the Information Technology industry before where this sort of thing has happened; usually with IBM as ‘dominant vendor’; the ones I recall are

    EBCDIC and ASCII, ‘what character set would you like’. IBM punch-card EBCDIC held sway from about 1900 to 1980; American Standard paper-tape ASCII (and its international extension UTF8) held sway from 1970 to present day. Even now, if you want to get from EBCDIC to ASCII you can’t do it fully automatically; if you’re given a deck of cards, you have to know whether it is Japanese or English, to get the ‘paper tape’ version anything like right.

    System/360 Floating Point numbers, and IEEE754 floating-point numbers. S/360 floating point was designed by IBM engineers; IEEE754 was designed by a vendor-neutral committee of mostly-US engineers.

    In those cases, it would have been pointless for ISO to ask for a change to EBCDIC or S/360 floating-point; punch-cards (or floating-point numbers) would not have interoperated pre- and post-standardisation, even if anyone had implemented “ISO S/360 floating point” or “ISO-standard punch cards”.

    So I understand that people have to show up in Geneva and vote. But I don’t really understand what it is they are attempting to resolve, to get altered to suit better.

  5. Chris, as I understand it, the question is not whether or not MS will change Office2k7 to make it ‘compliant’ with the standard – it’s clear that this will not happen. The vote is whether or not the ‘memory dump’ that is MSOOXML is worthy of being called an ISO standard – does it meet the minimal criteria for ISO standardization.

    If it does not, there is nothing that prevents MS from continuing to change it at will, but there is an additional marketing barrier introduced (as there should be) when competing against true ISO-worthy standards. If this means that MS cannot arbitrarily modify its standard to preclude competition wihout simultaneously invoking that market barrier, that is a good thing. If it means that MS provides sufficient additional information to allow 3rd parties to interoperate at 100% instead of the current 40%-90% with MSOffice documents, that too is a good thing. If this means that customers get caught in the middle of a FUD-storm with MS claiming ‘standards-compliance’ and everyone else being able to point to ISO rejection of MSOOXML and their own compliance with ODF, that too is a good thing as it raises awareness of the level of duplicity that MS is willing to employ in the name of sales.

    Furthermore, if MSOOXML *does* manage to get approved, future versions of MSOffice will either have to stick to the MSOOXML specification or risk the marketing backlash when the ODF backers publicize Microsoft’s failure to support their own very public format to their own marketing advantage.

    Either way having the vote in Geneva on MSOOXML will determine with finality the current qualification of MSOOXML to bear the mark of OSI approval. It remains to be seen whether future versions of MSOOXML will continue to abide by MSOOXML however the Geneva vote goes or whether MS will abandon MSOOXML at the first opportunity, thereby proving that the MSOOXML nay-sayers were right all along.

    If the MSOOXML BRM manages to get some of the technical fixes incorporated into MSO2k7, that too is to the good since ODF spreadsheets would then produce the same answers as MS spreadsheets in the areas of trig functions an statistical packages and date functions. Failure for MS to correct the operation of MSO2k7 and earlier versions after having the technical and mathematical deficiencies pointed out during the OSI process will probably be viewed by many as reasons *not* to rely on MS products and/or reasons to switch to ODF-based products where one can more reliably depend on the spreadsheet-calculated answer and a stubby-pencil answer to agree.

  6. Even if ISO does issue a standard, other vendors aren’t going to be able to interoperate at 100% with MSO2k7 .

    Several people have tried, by using the 6000-page draft and also by using people-power on the human-readable XML.

    A non-Microsoft app trying to read Microsoft’s XML will in general misunderstand something. And a non-Microsoft app trying to create Microsoft’s XML will in general create something that MSO2k7 chokes on.

    So I think anyone who wants interoperability through standard formats is going to stick with ISO26300.

  7. You raise some good addtional points. I suspect your predictions are right on as well.

    I think this is all one more demonstration that Microsoft has some serious problems. If the standard goes through and no one can use it despite the implementation being OOXML-compliant or if no one can make an interoperable MSOOXML product, then I can see development moving en-mass to ODF and that ecosystem growing at the expense of Microsoft.

    If the standard is not passed, I see the Microsoft partners still trying to work to ECMA 376 and failing due to the technical deficiencies of the ECMA spec that you reference above.

    Either way, I see Microsoft abandoning this spec in the very near future as they “EEE” their own protocols with addtional, non-documented, vendor-specific tags for Sharepoint, .NET, Silverlight, etc. that will not be in ECMA 376, nor in any 3rd-party package.

    I currently do not see any realistically viable alternatives to ISO26300 for 3rd-party implementations/interoperability with office documents going forward given the less-than-sterling acceptance of MSO2k7 to date in the marketplace and given that the more MSO2k7 that ships, the more entrenched Microsoft becomes against changes at the BRM.

  8. Bob hi,

    Taking your points in order:

    1. A formal invitation has been issued by the SC 34 Secretariat to National Standards Bodies eligible to attend. These NBs can propose delegations of any size — but of course adjustments may have to take place if the meeting is oversubscribed — in this case it will be up to NBs who in their delegation makes the cut.

    2. Decision-making within delegations is a matter for those delegations; the delegation head then gets to register the the vote. In general, delegations are representing their national position(s), not individual points-of-view. As the JTC 1 Directives state, delegations are to be “well aware of the NB’s position”.

    3. Delegates are officially accredited representatives of National Standards Bodies, and it up to those Bodies how they support (or not) the expenses delegates incur. Often standards-meeting attendees need to pay their way out of their own, or their employers’ pockets. ISO rules allow for meeting to be sponsored and I had half a thought that some of the big corporate interests in this event might want that honour. IBM too maybe … ?

    4. Yes, the whole meeting gets to consider the topics that come up.

    5. I don’t expect the result of any in-meeting votes to be made available via a public document. (N.B. In-meeting votes would be on details of the text, not on the approval of the DIS.)

    6. If the meeting decides on changes, it will emit inviolable instructions to the Project Editor to effect them.

    7. It’s quite usual for a Project Editor to offer to defer fixes until later in the process; when this happens NBs need to take a view on whether this is acceptable.

    – Alex.

Comments are closed