I wrote a piece based on a report from Polishlinux "NoOOXML: abstain from voting". A friend from Poland corrected me.
Don't jump to conclusions based on fast, dirty and partial translation only. In last part of his letter Mr Schweitzer refers to public consultation procedure from August 2007 and suggests that its indecisive results would be best represented by "vote of abstention".
Ms Andrukiewicz got the message. She tried to hide this letter from KT182 meeting participants making them really angry. In fact Mr Schweitzer decided to publish his letter on PKN mainpage to reach KT182 members over the Ms Andrukiewicz head.
Finally KT182 members were asked to answer two questions in e-mail ballot:
1. Do you support current Polish position (approve)?
2. If no, what position should Poland take (approve / abstain / dissaprove)?
Of course then Mr. Schweitzer's abstention vote is a wise suggestion while I personally find that disapproval is the only appropriate decision on technical grounds. Political considerations ("multiple Standards", appropriateness of fast-track, public image of the ISO system, behaviour of the main proponent etc.) only further add to these technical considerations.
Microsoft's OOXML pope Doug Mahugh mentions that a switch is unusual (what is business as usual in this process?):
It's quite rare for a country to shift their vote in a negative direction at the end of a JTC 1 Fast-Track process, by the way. (I think only one country has ever done that — anyone know for sure?) The reason is obvious: if you have a BRM and make a bunch of changes or improvements that countries asked for, then the spec is probably better than before, or at the very least no worse than before.
What Doug fails to address is that member states committees did not know the comments filed by the other member states. Imagine three people read a document and each of them finds three different orthographic mistakes. How many mistakes are then in the document? 3 x 3 = Nine. If you give a mark based on the mistakes your committee spotted you can say you are okay with it. However, the September vote did demonstrate that there were far more errors than you found. The prolonged review period through the BRM made many participants to study the 6000 pages more intense than before. Doug continues to explain why standard bodies should strictly focus on the formal process rather then to consider the whole picture. An he criticizes those who "found more":
Raising new technical objections. Many national bodies are being asked to consider brand-new technical objections to the DIS29500 standard, even though the 5-month period for submitting such comments concluded long ago in September. Then, when somebody points out that there is no process for resolving such comments until the future maintenance period, the lobbyists say "see, the process is broken!"
The point is: there are indeed problems that the national committee discovered in the review process, valid technical issues that were voted down by a Microsoft partner majority, valid technical issues that could not get submitted due to voting irregularities (e.g. Sweden, Netherlands), and all the issues the others discovered but your standard body not. And during the BRM period you were made aware that the ECMA dispositions also contain technical issues that were adopted en bloc. And finally all the issues we discovered after the September ballot. The unability to address the new issues is due to the process. But still OOXML should not be published as a standard when you have a very large corrigenda list in the drawer.
Poland is well advised to consider the whole picture.