OOXML: Open Letter to YES-voting and ABSTAIN-voting Countries

I am learning a lot from all this standardization process.

I was a member of the brazilian committee and I also analyzed the specification. My country disapproved OOXML and I think this was a decision based on logic lead by the process.

The JTC1 rules page 49 item 9.8 says:

NBs may reply in one of the following ways:

  • Approval of the technical content of the DIS as presented (editorial or other comments may be appended);
  • Disapproval of the DIS (or DAM) for technical reasons to be stated, with proposals for changes that would make the document acceptable (acceptance of these proposals shall be referred to the NB concerned for confirmation that the vote can be changed to approval);
  • Abstention (see 9.1.2).

[Note: Conditional approval should be submitted as a disapproval vote.]

In other words, from my understanding, if there is one or more technical problems, the NB must disapprove the DIS. Many countries found many technical problems in OOXML that are still unresolved even after the BRM.

I also understand that such an important matter as an International Standard for Office Documents can’t be defined by 10 or 30 opinions collected as votes in a committee. Thats why the JTC1 process above talks about technical content, not opinion or vote. What I learned from studying the OOXML specification is that it is not ready for acceptance since many countries have found and reached consensus that the spec has problems, even after the BRM. If the NB-leveraged technical team — formed by people that would vote YES and NO — has produced a list of submitted problems in the spec, this list is by itself the consensus that the spec is still problematic.

I would like to understand why an NB that has produced technical comments voted YES or ABSTAINED. I thought abstention is a position for countries that were not able to create a committee to technically discuss the specification for reasons such as logistics or lack of quorum.

I am learning about all this and I’d like to have more solid arguments to build an opinion about these NB’s maturity to run a well documented process.

10 thoughts on “OOXML: Open Letter to YES-voting and ABSTAIN-voting Countries

  1. Very good points, especially the last two paragraphs. I think your statement on reasons for abstention are more concise and logical than I have otherwise seen.

  2. If you think any company that were not able to create a committee to technically discuss the specification should vote ABSTAIN you are correct.

    Reality is somewhat different. Here is answer to official request from Russian’s Duma (Russian parliament) member: http://v-alksnis2.livejournal.com/66629.html

    It’s in Russian and you’ll need official translation if you want to protest but basically it says “we faithfully followed OUR OWN procedures and they say: if no response from technically committee – vote YES”. It was sent by clerk, not even by some person in power. Who needs any lobbing or bribing with rules like THAT?

  3. “In other words, from my understanding, if there is one or more technical problems, the NB must disapprove the DIS.”

    How do you get that idea? I have never heard of anyone suggesting it before. Did your NB vote on the basis of this mistake?

    What voting Yes means is not that there are no technical problems, but that they are not showstoppers. Compromises are often necessary.

    Rick Jelliffe

  4. Rick, there is a note after these points in the JTC1 rules. You can read it in the quote: “Conditional approval should be submitted as a disapproval vote.”

    Brazil’s NB voted according to these rules, and I think they are correct.

    Not showstoppers are editorial problems. Problems like 5 ways to represent dates, lack of a mapping between the old binary formats and the new OOXML, binary blocks inside an OOXML document, lack of documentation to many parts of the OOXML schema etc etc etc are complete technical valid showstoppers.

    Not to mention the IP problems, the 95% overlap with ODF (two standards equals to no standard at all) and others that are not so technically driven.

  5. Oh, and Rick, you never hear this idea before, probably because, apparently, NBs don’t have enough maturity to even read and understand the JTC1 rules.

  6. Rick Jelliffe said: “Compromises are often necessary.”

    Compromise apparently being defined as “Whatever Microsoft wants”.

    This has been a farce. OOXML was never suited for fast-track, is not implementable, even by Microsoft, is certainly not open, and will never be a standard in any sense that word was originally intended to mean.

    The rules are clear enough, but apparently a number of participants were only reading the version that had passed through an OOXML translator…

Leave a Reply

Your email address will not be published.