US to vote “yes” on Open XML

Similar to what we just saw from Germany earlier this week, the US has voted to approve Open XML as an ISO standard. The result of the vote for "yes with comments" is posted here:

As I pointed out yesterday, Ecma has already publicly committed to dealing with all comments that have been raised by national bodies, and I've seen some pretty good ones coming in so far. The review that Open XML has undergone during this process has been phenomenal, and we'll see a much better specification as a result of it. I haven't seen many comments come through yet that will be too difficult to deal with, so it should be a fun several months working towards the Ballot Resolution Meeting. The majority of the comments are seeking to have bugs in the spec fixed, or further clarification on specific details.

We're already working within the Ecma TC to create a good system for collecting all of the comments and properly categorizing them as we've seen a number of the same issues come up in multiple countries. We're also looking into ways to assign any comment to a specific change in the spec. This way people can quickly see what the actual change was that resulted from their comment. Quote of the Day:

Global Learning and Consulting Corp – Puerto Rico

"The adoption of Open XML as an international standard is a very important step, because it represents the most complete format for the type of documents used in productivity applications for the office. It makes it easier for our customer and us to generate, to process and - on a long term - to archive this information. Office Open XML will help to close the gap between processing structured and unstructured information in an easy, comprehensible and transparent manner."

- Ernesto Rivero – General manager


Comments (7)
  1. hAl says:

    Questions on the comments

    Will there be a full list of suggested edits


    Will there be a a complete new format specification presented to the BRM that will already have including the edits combined with a list of which edits that were made.

    Will you split the edits in categories ?

    * editorial

    * minor bugfixes (omissions, xml validation errors)

    * major bugfixes (wrong formula)

    * technical issues (bitmask, comapitibiltiy tags)

    * other issues (IP, opendocument, VML)

  2. says:

    Hey hAl,

    Right now we’re definitely planning on categorizing the issues. The other things we’ll probably need to do is work with the various national bodies to help determine which are the show stopper issues so that we can do a good triage pass.

    The other thing that’s been talked about is having Ecma produce a few "drafts" of the spec with various changes applied. This will allow people to have ample time to review the changes before the BRM.


  3. Andre says:

    Brian, the format is not your business anymore. It now belongs to ISO, not ECMA and not Microsoft. And I hope they will ensure full ISO 26300 compliance of OOXML. ECMA is no member of the BRM and I don’t think anyone would let the ECMA get in charge again. So forget your EC45 wet dreams. The format is broken and ISO can fix it. It is essential that Microsoft stays out of the process

    — Andre

  4. says:


    Ecma does indeed play a role in the BRM. Ecma is allowed to submit it’s own list of technical comments it would like to see addressed. Ecma also plays a big role in trying to organize the comments and provide the necessary changes to the spec.

    I am on the Ecma technical committee and will stay heavily involved in Open XML going forward, as I care deeply about it’s continued evolution.


  5. marc says:

    Interesting comment of Frank Farance ( one of the  few Incits member that maintained his NO vote between the first[1] and last[2] letter ballot ):

    [Brian Jones 8-24-07] Marc had initially included all of Farance’s comments, but it’s easier to just include a link rather than take up a few pages in the comments field:



  6. Andrew Sayers says:


    Moving beyond standardisation, I’m a bit worried that we’re heading towards a bad maintenance process.  I’ll lay out my case first, then ask some questions to see what can be done about it.

    The Office Open XML spec seems to allow features that solve quite narrow, specific problems – or at least, it doesn’t seem to have been a goal that features included in the spec should solve problems that are as general as possible.

    Also, the first version of the spec was (necessarily) developed in-house at Microsoft before being taken to ECMA.

    If Microsoft develops narrow features in-house after the maintenance process begins, and doesn’t send them to ECMA until they’ve been fully implemented, other implementations could be left in a permanent state of catch-up, because they’ll only ever be able to start implementing features once they’ve stabilised in Microsoft Office.

    So I’d like to ask two questions:

    * Would you expect feature requests to be sent to ECMA as soon as the need is seen, or once source modifications start to be made, or after the feature has stabilised in the Microsft Office source tree?

    * Where a desirable new feature is conceptually similar to an old feature, would you prefer to add a more general feature that obsoletes the old one, rather than having two narrow non-overlapping features?

    – Andrew

  7. John says:

    Hi all,

     Who decides who votes on these things BTW?



Comments are closed.

Skip to main content