I was at the OOXML BRM in Geneva on behalf of my national body. We were trying to improve the Ecma 376 OOXML specification (i.e. what many people think of as the spec for the Microsoft Office 2007 file formats), in preparation for national bodies to make the final decision as to whether it should be accepted by ISO as a standard. I’m not going to blog about the details of it, because that’s already been done well by plenty of people already (Antonis Christofides, Tim Bray, Jesper Lund Stocholm, Rob Weir, Yong Yoon Kit, Doug Mahugh, Brian Jones).
What I don’t think has been covered well is what happens now, and what people can do about it.
What happens next
Now, the various national bodies receive reports from their delegations, and make a decision on whether to keep their previous vote, or to amend it. Some countries will have already made that decision, some won’t. In some countries, such as the US and the UK, a technical committee will produce a recommendation, and another committee will take the final decision, taking the technical recommendation into account.
What you can do about it
Realistically, blogging about it will do very little to affect the votes. That’s not to say that it’s not worthwhile blogging about the issues - it is. But not many NB committee members read blogs, and those that do are unlikely to be convinced by most of the arguments on blogs.
If you have strong feelings about the procedures used in the voting (e.g. the O members vs P members debate, or the voting on issues that were not individually discussed):
- Contact your national body
- Describe your concerns (with reference to the appropriate directives, if possible)
- Allegations of corruption are unlikely to convince anyone of anything
- Ask your national body to investigate, and to raise an objection to the process if they are not satisfied
I suspect that most national bodies will prefer communication via email - it’s easier for the NB to distribute it to any relevant committee members. But some people feel that emails are cheap and easy, and sending a letter on paper carries more weight: if you agree, then just be aware that there isn’t very much time before the decision on voting is due.
If you think that there are technical problems in the specification:
- Have specific technical complaints. Generic and unsubstantiated “it’s no good because it can’t be implemented” claims are likely to be ignored.
- Check that the issue you’re concerned about hasn’t already been fixed in the BRM (e.g. non ISO dates, use of bitmasks, autoSpaceLikeWord95, etc.). There’s a good high-level summary of the resolved problems at Rick Jelliffe’s blog, and you can look at the details for yourself via Alex Brown’s blog.
- Check that the problem you’re concerned about wasn’t fixed by an Ecma disposition that was accepted at the BRM (again, via Alex Brown’s blog).
- Write up your complaint. Remember that a typical committee will have some members who have in-depth technical knowledge about OOXML, and other members who have experience in other areas. Ideally, you want to make your complaint clear to the latter, and with enough substance to convince the former.
- Email your complaint to the national body, blog about it, and publicise your complaint via sites like ConsortiumInfo.
- Any problems in the newly adopted resolutions from the BRM are particularly interesting. These were mostly drafted at the meeting, and although they were scrutinised and argued about by many delegations, there is still the possibility that there are subtle problems present because they haven’t had the same time for review as the rest of the dispositions.
- Any problems that come from real implementation experience are particularly interesting. This is why Jesper Lund Stocholm’s comments and Stephane Rodriguez’s comments are more interesting to me than many other comments.
- If the problem is serious, then that’s a good argument for your national body to reject OOXML on technical grounds (and if it’s not rejected, then having a list of known problems is very useful so they can be fixed in the maintenance process).
Good examples are Groklaw’s post on the use of MP3 with OOXML (Groklaw is wrong, as I explain in the comments, but Groklaw are doing the right thing), or Rob Weir’s post on OOXML macros (which I think makes a good argument).
If you think that there are other problems (e.g. IP issues, unsuitability for a fast-track process, contradiction with ISO 26300, size of the specification, etc.):
- Be aware that your national body has likely already received many letters on these issues. One more letter is unlikely to make any difference.
- If you have something new to say, or a particularly eloquent argument, then send it to your national body, and blog about it so others can see your argument too.
If you want to express your enthusiasm for the specification:
- Be aware that your national body has likely already received many, many form letters in support of OOXML, and that any more are unlikely to make any difference.
- If you are writing something original, particularly if it’s an area in which you have expertise, then send it to your national body, and blog about it so others can see your argument too.
I look forward to receiving high-quality arguments via my national body!
Update: the No-OOXML site has a list of national bodies and their contact details. I don’t know whether this list is complete and correct, but it looks plausible.
I’ve written about OOXML before when I reviewed the examples in the draft spec and found many problems with them. This was adopted by the No-OOXML campaign as item 4 on their petition.
Disclaimer: I am posting this as myself, Inigo Surguy, rather than as a BRM delegate, a representative of my country, or as an employee of my company.