Share via

BRM results publicly available

  • Article

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

  • Anonymous
    March 06, 2008
    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. So: 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? yk.

  • Anonymous
    March 06, 2008
    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

  • Anonymous
    March 06, 2008
    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. --Andre

  • Anonymous
    March 06, 2008
    The comment has been removed

  • Anonymous
    March 06, 2008
    The comment has been removed

  • Anonymous
    March 06, 2008
    The comment has been removed

  • Anonymous
    March 06, 2008
    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 ... -Julien

  • Anonymous
    March 07, 2008
    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 noooxml.org ?

  • Anonymous
    March 07, 2008
    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?

  • Anonymous
    March 09, 2008
    Dough, Julien, About the stickers - I couldn't help it ... check it out at http://idippedut.dk . (the first batch of stickers has been ordered) :o)