Here's a bit more information on the results of the BRM last week, and where we go from here. There were about 1,000 comments/issues raised last year with the spec, and starting last fall Ecma began posting responses and proposed changes to the specification to address the concerns. The final batch of responses was posted mid-January, and at that point Ecma had already begun discussions with the national bodies who had raised the comments to see if they were suitably addressed.

For the past two months, Ecma officially held 4 calls per week where national bodies could discuss the comments, and Ecma could explain their proposed resolutions. This meant that by the time we got to the BRM, the countries had time to find which Ecma responses they were not quite satisfied with, and raise those issues at the BRM. The purpose of this entire process is to make improvements to the specification, which in turn may lead countries to change their vote on whether or not they approve the overall spec.

While it's a matter of opinion whether or not the BRM itself was a success, in my mind a number very important things happened (I'm not sure if I'm allowed to mention countries by name in terms of the work done, so for now I will avoid it):

• 98% of Ecma responses approved – This was very important. The Ecma responses consisted of a number of changes to the specification in order to address the concerns raised by various countries. These were issues that one or more countries felt were problematic in the spec, so it was important to make sure the feedback from those countries were heard, and that the spec was modified to address those concerns. Most people at the BRM that I talked to agreed that without question, the changes proposed by Ecma made the spec better. Voting to approve a comment means that you feel the spec is better with the change than without. This is why it would have been odd to see the changes voted down, which would have meant countries felt the spec was better before the change. Some countries voted "yes" as the default for all the comments, some voted "no" as the default for all the comments, and most countries didn't give a default vote. Then the countries picked any individual comments they had reviewed where they in essence wanted to give a direct "yes/no" vote (overriding the default vote). It shouldn't be surprising that many countries only reviewed their specific issues, and in these cases they often decided to abstain from voting on the rest.
• More changes were proposed at the BRM – There were a number of issues where folks wanted to see the proposed changes go further. Even in these cases, most of the countries felt that the Ecma responses made the spec better, so the original Ecma response was approved. We also would work in groups to add additional changes on top of the Ecma proposal. I'll now list some examples of these changes.
• Transitional and Strict conformance – A number of folks weren't comfortable with the deprecated annex, and wanted us to go much further. So a few countries, with the help of Ecma folks came up with a new proposal where there would be two types of functionality: transitional, and strict. Conformance is defined in terms of transitional and strict, and there are even two versions of the schemas (transitional and strict). All of the legacy features that we had previously marked as deprecated, will instead now move into a new part called transitional. If you are going to create a strict document, than you are not able to use any of the transitional features (legacy compat settings; VML; old date bases; etc.).
• Multi-part – We will split the specification into 5 parts. The five parts are essentially: OPC; Markup extensibility; Primer; Strict markup; Transitional markup. [update - I forgot that we changed this so that the primer is actually tied into the first part, so in the end we have 4 parts, not 5]
• Dates – This was definitely a hot button issue. I worked with a large number of national bodies to come up with an updated proposal to solve the issue of dates in spreadsheets. One national body had an alternative proposal that we discussed, and between a number of countries we were able to come up with a fairly elegant solution. We introduced a new data type for cell storage which was "date". Previously dates had been stored as numbers, but with this new proposal, we have a "date" datatype, and the only allowed way of storing date values in cells of this type is with ISO 8601. We also simplified the concept of date bases, which are used when converting from a number into a date (mainly done in calculations). ODF has a similar concept where you can essentially set any date in history as the epoch. In our case there is only one way of doing this for strict documents, and the two legacy bases can be used, but only in transitional documents.
• Accessibility – Thanks to two very influential countries, there have been a number of very significant improvements in terms of accessibility in the file formats. A new accessibility annex has been added, as well as some additional functionality for tables that helps make them much more accessible.
• Function clean-up – We had a couple countries work on cleaning up some of the spreadsheet functions, as well as introduce the concept of prefixing (sort of like namespaces) for functions. This will help as we move forward with the next version of the spec, as we can start to add new/improved functions in the ISO prefix, and keep the legacy behaviors in the Ecma prefix.
• Bitmasks – We had a national body propose a change to the spec in order to remove the use of bit fields, and instead use XML markup to represent the same values. Ecma had discussed this for a few weeks before the BRM with the national body, and that's how we were able to come up with a great joint proposal on these modifications. The original Ecma proposal was to not remove the use of bitfields, but to instead provide an XSLT in the annex that displayed how to work with bitfields. The feedback we received though in the weeks leading up to the BRM was that this did not go far enough, so in the BRM it was decided to actually change the format as well.

It was really a crazy week, and I know that a lot of people went without sleep as we worked around the clock to make the most of the opportunity. It was a chance for everyone to discuss additional things they wanted to see done with the spec, and also to meet those folks who will probably be involved in the next version of the spec as it enters into maintenance (assuming it is approved this month).

Thanks again to everyone who spent so much time helping to build a better specification. I know that it will continue to improve over the years, and I think we really have some great momentum now going into the coming maintenance.

-Brian