BRM results publicly available

I see over on Alex Brown’s blog that the results of the BRM are publicly available now. There are two documents available from the SC34 web site:

These documents show the specific resolutions that were passed at the BRM, and are the definitive record of what was accomplished. I saw that Brian Jones provided some thoughts on a few of the major areas of progress earlier this week, and now you can look at these documents and see exactly how those items were resolved. The goal of the BRM is to improve the text of the standard, so the resolutions are always phrased as specific editing instructions for the project editor.

Here’s one example of how that worked: Resolution 21, covering the differences between ECMA-376:2006 and ISO/IEC 29500. Here’s the text from the resolutions document above:

Resolution 21: The BRM decides to instruct the Editor to incorporate an informative specification of the following, with a reference to it from the Scope:

– All XML elements which appear in ISO/IEC 29500 but do not appear in ECMA-376:2006
– All XML elements which do not appear in ISO/IEC 29500 but appear in ECMA-376:2006
– All XML attributes which appear in ISO/IEC 29500 but do not appear in ECMA-376:2006
– All XML attributes which do not appear in ISO/IEC 29500 but appear in ECMA-376:2006
– All enumeration values which appear in ISO/IEC 29500 but do not appear in ECMA-376:2006
– All enumeration values which do not appear in ISO/IEC 29500 but appear in ECMA-376:2006
– All simple types which appear in ISO/IEC 29500 but do not appear in ECMA-376:2006
– All simple types which do not appear in ISO/IEC 29500 but appear in ECMA-376:2006

—so resolved.

So in that case, the editor has been instructed to add informative text that lists these various differences, and then reference that informative text from the Scope clause. This was decided because some people felt that these differences would be important to those who have large quantities of ECMA-376 documents that may use features which have been altered or removed in the final revised DIS 29500 text.

It’s been interesting to see how much time various people are devoting to spinning the BRM in the days since it concluded. Now that the actual minutes are available, I’m hoping the spin can slow down and we can all get focused on the real output of the BRM, which was a series of consensus decisions about various editorial and technical issues. Everyone is entitled to an opinion, but the consensus of the BRM delegates was well-documented and isn’t something we need to speculate about any longer now that the documents are publicly available.

Resolution 21 above, for example, is the only resolution that covers ECMA-376 documents, but you might have got a different impression from Yoon Kit’s post last Friday:

We eventually found out that if any changes affected current implementations it would certainly be rejected. This seriously compromised any elegant solutions, and it forced us to be mindful of the “existing corpus of documents” in the wild. I personally don’t believe that that should be our problem, but there was a large and vocal voting bloc which would oppose any changes to the spec which would ‘break’ Ecma 376.

In this case, the majority consensus in the BRM was that compatibility with ECMA-376 documents is important enough to merit accurate documentation of the breaking changes between ECMA-376 and ISO/IEC 29500. Many such changes have been made, which implementers of ECMA-376 will need to deal with, and I think identifying these changes was a good addition. Resolution 21 passed without objections, so it seems most everyone at the BRM felt the same way about that one.

I’ll post some thoughts on other specific resolutions in the days ahead. If there are any specific topics you’ve heard were decided at the BRM and you’d like to understand better, let me know and I’ll start with those.

By the way, if you were at the BRM I hope you picked up one of those cool “Have you read all 6,000 pages?” stickers they were passing out outside the elevators leading in and out of the room. I love mine …

Copenhagen airport

Comments (10)

  1. Hi Doug,

    Although Norway brought this issue up on the 2nd day, it has to be made clear that Resolution 21 (and the Scope) only got resolved on the LAST day of the BRM. Additionally, I believe it was also only resolved very late in the day .. approx 3pm?

    This meant that throughout the week, it was unsure whether we as delegates had to heed the concerns of the "vocal voting bloc".

    If Resolution 21 was decided much earlier on, then the bloc obviously would have no grounds to object to changes, and we could have made further elegant improvements to the spec.

    Instead we had to assume that "backward compatibility" was a big issue, and dance around the legacy of Ecma376.


    Do you think that if Resolution 21 was decided earlier, we would have seen more change to the spec?

    And yet do you think that Resolution 19 and 20 would have some effect to the extent of changes too?


  2. Doug Mahugh says:

    Hi YK,

    Yes, I think that’s correct — Friday afternoon we finally resolved this one.  And it’s an interesting question whether more changes (more breaking changes, anyway) would have been agreed to if we had that framework in place earlier in the week.  I think it’s reasonable to wonder, although I can’t think of a specific example of anything that didn’t get changed which might have if resolution 21 passed earlier.  (Or 19/20 either.)

    One dynamic that I think isn’t completely obvious to those following along from outside the BRM is that the concept of breaking changes, and whether to allow them, didn’t always divide the room along the lines some might expect.  For example, in the US delegation you may have noticed that it was a person from a user organization that was most concerned about this issue, more so than I was (although my employer has existing implementations to worry about).

    – Doug

  3. Andre says:

    As I understand it ECMA-376 will be adapted according to a potential ISO 29500 spec?! Isn’t ECMA-376 the format fast-track submitted to ISO? Essentially the yk rule would mean self-backwards compatibility, right?

    Further Office2007 is different from ECMA-376.

    Just curious.


  4. I can. The equationxml attribute in VML would have been deleted and not just kept, as it was functionally replaced by the equationxml element. Both of them are transitional.

    That argument was also raised against the proposal for dates that only stored iso8601 dates but behaved as the users expected. Not allowed serialized numbers in the data was a problem because it was incompatible with ECMA-376 documents out there.

    Those are the two cases I remember from the top of my head.

    João Miguel Neves – Member of the Portuguese Delegation to the BRM

  5. Joäo,

    On the top of my head we specifically had two discussions where an attribute was left in the Schema. One was the equationxml-attribute you mention and the other was the securityDescriptor-attribute. The isodate you mention was due to a wish in the room for not making existing ECMA-376 document non-conformant – but it had nothing to do with serialization of dates itself.

    PS: Did you get your t-shirt?


    > Further Office2007 is different from ECMA-376.

    Is it?

  6. Inigo says:

    Hi Doug,

    I don’t think that Resolution 21 says anything either way about whether country delegations and Ecma were trying to preserve backwards compatibility with Ecma-376. All it says is that if there are differences, then they should be listed, which I think everyone would agree with.

    Certainly there were many changes made from Ecma-376, but off the top of my head, I can’t think of any that made existing Ecma-376 documents invalid. Several were proposed, but objections from various countries (not generally Ecma) meant that they were modified before being accepted.

    See also my comments on the Open Malaysia post you reference:



  7. Hi Doug,

    Great stickers on your laptop. I especialy love the ‘Have you read all 6000 pages ?’. I assure you that if you have a ‘Have you read at least 1 page ?’ I will distribute it to several committees members … Is that the same people that provided comments and make the ISO vote ? Unfortunately yes …


  8. Dough,

    I was actually not approached by a single OFE-chearleader during the event – so I was not offered any stickers … it kinda puts my alledged front-row-position in the (global) debate on OOXML in perspective … :o)

    So where do I get my hands on those stickers? I cannot seem to find them on ?

  9. Doug Mahugh says:

    Inigio, good point about breaking compatibility in the resolutions passed at the BRM.  I need to look at this carefully and make a list, so that we can discuss specific changes, but I know there are changes adding elements or attributes that weren’t in ECMA-376, or making optional items required and so on.  These may be in the separately passed dispositions and not the ones discussed on the floor — I’ll look into that and do a post with specific details.

    Very funny, Julien.  We should have had some of those to pass out at the anti-BRM.

    Jesper, you’re too polite.  I didn’t wait to be asked: I walked up and took a few.  Unfortunately my stash is depleted now.  Maybe we need to set up another Cafe Press item?

  10. Dough, Julien,

    About the stickers – I couldn’t help it … check it out at .

    (the first batch of stickers has been ordered)


Skip to main content