In many national committees members were told that "Yes with comments" is a valid procedure under which national comments would get considered by ISO. FFII insisted that "Disapproval with Comments" is the only meaningful method to get comments considered because this is found in the bylaws. Very late ISO clarifies: If you have comments you must vote disapproval.

Confirmation by ISO (finally!): If you have comments you want to get resolved, you must vote "CONDITIONED NO". So many members of national Standard Committees who spent a hard time to debug the Open XML specification were deceived. They were told a "Yes with Comments" would ensure that their comments would be considered by the ISO. ECMA added to the confusion that they would consider all comments but ECMA has nothing to do with the standard anymore. In fact as FFII insisted a "Yes with comments" is a YES to the current broken ECMA-submitted specification with a kind of Christmas card attached. From the bylaws it is evident that "comments" to an approval vote are just editorial, but all comments need to be submitted as a "CONDITIONEDl NO". When you want your comments to get considered your nation has to vote "DISAPPROVAL WITH COMMENTS". If you thought otherwise ask your unbiased national Standards Committee that voted "approval with comments". I am sure they would you explain you the bylaws.

Bylaws

"9.8 Votes on Fast-track DISs
The period for fast-track DIS (or DAM) voting shall be six months,
consistin of a 30-day JTC1 National Body review period followed by a
five-month ballot period. NMs may reply in one of the following ways:
-Approval of the technical content of the DIS as presented (editorial or
other comments may be appended);
-Disapproval of the DIS (or DAM) for technical reasons to be stated, with
proposals for changes that would make the document acceptable (acceptance
of these proposals shall be referred to the NM concerned for confirmation
that the vote can be changed to approval);
-Abstention (see 9.12).
Note: Conditional approval should be submitted as a disapproval vote.
The criteria for approval are given in 9.6. If these criteria are not met
initially but are subsequently met at the conclusion of ballot resolution
in accordance with 13.9, the DIS (or DA) is approved."

ISO ANSWER to Uruguay inquiry

Apart of the stablished in the proceeding that is refered, it was made a formal question directly to the Technical Program Manager of the Central
Office at ISO at Geneva assigned to the project ISO/IEC FDISK 29500. Mr. Brannon communicated via telephone with UNIT (Uruguayan NB) to answer the doubts that were addressed regarding the treatment of the comments in the alternatives of approval or dissaproval. His answer via e-mail is what is shown here:

UNIT: Our national mirror commitee has identified many comments to this DIS
and we have some doubts in how the comments will be processed by the WG
mentioned in 4.
Our questions are
1- Is it valid to send an approval vote with technical comments? In this
case, could we be sure that the comments will be considered by the WG
before the counting of votes mentioned in 5
Mr. Brannon: ALL COMMENTS WILL BE CONSIDERED BY THE BALLOT RESOLUTION
MEETING. YOU MAY SUBMIT COMMENTS WITH AN APPROVAL VOTE THAT ALSO MAY BE
TECHNICAL BUT YOU ARE NOT INSISTNG THEY ARE ACCEPTED AS YOU HAVE ACCEPTEDTHE TEXT IN VOTING APPROVAL
or
UNIT: 2- Is it valid to send a "disapproval vote", which could change to
"approval" during the counting of votes mentioned in 5 if the comments
are considered by the WG (conditoned vote).
Mr Brannon: YES IF IT IS A CONDITIONAL VOTE YOU MUST VOTE DISAPPOVAL WITHTECHNICAL COMMENTS AND INDICATE PROPOSALS FOR CHANGE THAT WOULD MAKE THEDOCUMENT ACCEPTABLE AND A CHANGE OF VOTE TO APPROVAL.
We will appreciate very much your prompt reply."

We were told that regardless of yes/no ECMA would be acting on any submissions.

Of course acting on submissions may just mean following them or discarding them.

And when it comes to more contentious points like obtuse XML which they regard as a selling point (parsing speed) I really doubt that they'd change just by being asked. I think voting "No" was a good way of leading Microsoft with a carrot.

I'm very sad to hear how the process was thwarted in this manner. Please send this information to Rob Weir at IBM. Rob is collecting evidence of cases of misinformation, and I'm sure he would like to hear from you. I have sent him a link to your post above, but because it is formally anonymous (even though you did sign it, its origin can not be validated), it is better if you send a message directly to Rob at moc.riewbor|citna#moc.riewbor|citna. We need to get all the lies, big and small, out into the open and trace them back to their source.

I would much prefer to see Dr. Empain contact ISO directly. Or even indirectly via Rob Weir or FFII, but in person via e-mail, rather than in an anonymous post in a forum. First hand information is always a lot better in these matters, as it cannot be discredited as easily.

The point is that Microsoft told NB's that they could vote "yes" or abstain and still attach technical comments. The FFII argued that only a "no" would treat the comments as significant; a yes or abstain would mean the comments have no weight. This is obviously what Microsoft wanted. A "yes with technical comments" is not a valid vote, it is a deception. ISO now clearly backs up this analysis: if a NB accepts the text during voting, it cannot also insist that the technical comments are accepted.

If you actually look at the comments submitted with those "yes with technical comments" for ISO 26300, you will see that they were indeed minor and not conditional for the approval of the standard. For DIS 29500, there have been several instances of "yes" votes with a large number of quite fundamental objections. This is highly irregular, there is no question about that.

In case you didn't know, ISO 26300 was passed with only "yes" votes. No serious objections at all were raised. Sure, flaws and mistakes have been found, and the standard keeps evolving to address that, but ISO 26300 was well reviewed and well prepared. DIS 29500 was not.

Many people are currently unhappy with details in ODF, and many people will continue to be unhappy with it and suggest improvements and extensions. ODF is in active use by lots of implementations, so it's in constant development. It's supposed to be under scrutiny all the time and keep developing to meet new requirements. There is nothing final about the current version 1.1 of the ODF standard, version 1.2 is already being developed, but even the first version 1.0 was an honest attempt at doing it right. Have you looked at ISO 26300? It is really a very different read from DIS 29500. The considerable time and effort spent in writing ISO 26300 is in clear and obvious contrast to the shoddy rush job with DIS 29500.

You're right about the comments having been submitted as part of an 'approve' vote. But you can hardly call these minor issues:

- ISO/IEC DIS 26300 document does not include requirements necessary for Arabic language users. To be useful to the Arabic user, the standard needs to take into consideration requirements necessary for Arabic language formatting styles and presentation…

- The text does not conform to Annex H of the ISO Directives defining acceptable verbal forms for the expression of provisions (i.e. the use of "shall", "should", etc.). It uses the conventions of IETF RFC 2119 instead. Our understanding is that the PAS procedure does not allow exemption from this requirement.

- Some standards that are cited normatively, e.g. RELAX NG, are citing a standard other than the ISO standard.

- It is suspected that no satisfactory normative reference exists for the ZIP compression format, unless it be a reference to the specification of the Java JAR format. The alternative is that the format should be fully specified.

- The ODF schema contains a number of features whose use appears to relate to specific implementation choices or be constrained by a specific implementation restrictions. Examples include features that are application-specific or which would only be available on specific operating platforms (such as DDE, OLE).
[ You've got to love that comment on the ODF specification :-) ]

- Add the features of accessibility, if possible.

So an 'approve with comments' is absolutely a valid vote even with complex/important/hard comments. Unless you want to suggest that ODF's approval as an ISO standard was done by following an improper procedure…

Those are some of the more serious concerns submitted, I can agree to that. However, I can certainly call those comments "minor issues" because of the intent with which they were submitted. To my knowledge, none of the "yes with comments" voters were expecting their comments to ISO 26300 (then DIS 26300) to be addressed before the standard was approved. By being either sloppy or devious in your choice of words, you are deliberately trying to lump together "complex/important comments" and "hard comments", i.e. you are not making the very important distinction between "suggestions for improvement" and "conditions for approval". Please stop confusing the subject, it is confusing enough as it is.

You should also note that many of the comments to ISO 26300 were editorial in nature, and that most of those were fixed in the final version. Editorial comments are supposed to work like that. What technical comments there were mostly stated something to the effect of "please fix this if possible, if not take it under consideration for the next version of the standard". ODF 1.1 later added the requested accessibility features, for example.

The number of comments to ISO 26300 was relatively small. The number of comments to DIS 29500 is huge. There is a lot of controversy on the subject, as some countries voted "yes" without any comments at all, indicating that they have no problems at all with the current document, some voted "yes" with rather a lot of technical comments, some voted "no" with a large number of comments, sometimes even fundamental objections, and many others had to abstain for lack of consensus. This is definitely reason for concern.

Furthermore, nobody ever suggested that there was any hint of irregularities behind the decisions and the vote for ISO 26300. If you want to point to any such irregularities, feel free to do so, but I doubt that you will find any accusations of ballot stuffing, misinformation, mud-slinging or strange applications of procedure in there. The dirty process is a fundamental reason why DIS 29500 is under suspicion, and it is a fundamental reason for you to drop the argument that ISO 26300 also had its problems. Of course it had its problems, I fully expect that no standards are ever passed entirely without flaws, but DIS 29500 is so much worse that it is simply pointless to try to make any useful comparisons to anything else known in standards history.

DIS 29500 is an extreme, abnormal case. No previous cases exist that compare even remotely to this one. Stop pretending that "ODF is just as bad" and "this is normal". Both of those statements are obviously false. Are you really not seeing the clear difference between the processes behind DIS 29500 and ISO 26300, or are you just trying to spread misinformation?

If you support NOOOXML honestly, simply ask yourself – who really lies?

Let's examine what you are saying here: Someone says to the Belgian committee members that "abstain with comments" is a valid vote. You are saying that this is nothing new, and say that "yes with comments" is a common vote from NBs. I really don't see the connection.
"Abstain with comments" is previously unheard of, and nowhere in the practice or in the ISO rules does it say that this is a valid vote. You are avoiding the actual issue at hand. Did you think people would not notice? You are spreading misinformation. Stop it.

Even regarding the common practice of "yes with comments", NBs were in this case badly informed of the nature and status of conditions attached to a "yes" vote. ISO finally clearly stated that we have read their procedures correctly all along: only "no with comments" guarantees the comments will be addressed, and any comments sent in with a "yes" vote are not supposed to be important technical issues. Such comments are expected to be editorial or minor and relatively unimportant.

ISO now says that a conditional approval should definitely be expressed as "no with comments". However, a large number of NBs have repeatedly been told that a conditional approval can be expressed as "yes with comments". I would call that a lie. What would you call it?

It is correct that you can attach comments to a Yes vote, mostly editorial ones. But a YES is a YES for an unaltered specification. The fast-track process was not designed for heavyweight technical issues. And voting Yes with comments means that your comments don't have to be considered.

If this is the case, and the only way to get comments in is to vote no, then all those who voted with "Yes with comments" or "Abstain with comments" should be treated as "No with comments".

For example apart from the corrupt discarding of the original 80% no vote by the technical committee and changing of the committee to one which excluded non-Microsoft affiliated participants from the second committee, Poland voted Yes with 4 comments. Hence even this corrupt vote should be interpreted as "No with comments".

ISO indeed has a huge job ahead of sorting out the mess with all the different votes being cast. In any case, I think it's reasonable to assume that if comments sent in with "yes/abstain with comments" are not resolved, some NBs are likely to change their vote to "no" in February, as ECMA assured them that such comments should be resolved.

Unfortunately, ISO rules are not explicit towards comments. You can then read them with 2 'options' in mind. Both options are used when drafting procedures or legislation so there is no way to a priori eliminate one of them.

Reading Option 1: Only what is written is allowed (meaning what is not written is forbidden) or
Reading Option 2: what is not explicitely forbidden is allowed.

Option 1 means Yes vote may only have Editorial or other comments (BTW, it is unclear what other refers to). Abstain may not have comments. No vote may only have technical reasons

Option 2 means Yes, Abstain or No votes may all have all sorts of comments. No votes must have technical reasons (btw not qualified as comments in the bylaw but OK …)

Looking at various other votes, it seems that Option 2 is the most common understanding. For example, per the discussion above, ODF voters expressed Yes votes with technical comments. Mr Brannon, above also, considers that a yes vote with technical comments is 'legal': "… YOU MAY SUBMIT COMMENTS WITH AN APPROVAL VOTE THAT ALSO MAY BE TECHNICAL …"

Given the heated debate around Open XML, it is unlikely that a rational scrutiny of the wording will be applied and a common understanding reached by all parties. Therefore, only time will tell.

If I'm correct with option 2, we'll see Yes votes with technical comments, No votes with technical and non technical comments and Abstain with comments. We'll know in a few days.