Here are the appeals to the ISO from India's Bureau of Indian Standards and Venezuela's standards body, FONDONORMA, regarding OOXML, as text, thanks to Steve Martin, once again, and Erwan. The PDF is here, if you wish to check it. India's section begins on page 13. Venezuela is on page 15. I've grouped them together because their issues are similar. We've seen and commented on
Brazil's appeal and that same link takes you to a text version of the ISO/IEC's responses. If someone has time to help do a text version of South Africa's appeal, I'd appreciate it. India, like Brazil, is bothered by not having the final text within a month, as per the JTC 1 directives, particularly when so many changes were voted on at the BRM. How can a national body know whether or not to appeal without a final text to analyze? So it asked that the window to appeal be extended, so that it had the opportunity to examine the final text. Venezuela challenges the entire process and says it undermines ISO's reputation. It raises the issue of a bad precedent being set, whereby large companies can exercise undue political pressure on a decision about a standard, instead of letting technical people work through and solve all the technical problems, which is what ISO normally has a history of doing quite well, from all I've heard: The result of DIS 29500 has harmed the reputations of both ISO and the IEC, as well as all they member bodies, and has generated a terrible precedent in which the interest of large multi-national organization, both in favor or against an specific proposal, may dominate the debate instead of the technical discussions necessary to produce the optimal solution on every specific problem. That really gets to the heart of the problem, in my book. So this was a first, as far as Venezuela is concerned, and one that it worries will start a new trend. It provides a list of comments on technical problems it raised, or tried to, that it feels were not appropriately handled at the BRM.
With regard to India's issue that a JTC 1 directive was violated by not releasing the final text within a month and its request to have more time to appeal until a final text was available to work from, the ISO memo sent to the Technical Management Board with analysis and recommendations regarding the appeals said: 6. "Final" text of ISO/IEC 29500 or ISO/IEC DIS 29500, or "revised FDIS text", not released
6e. Correct but irrelevant. The decision being appealed is the JTC 1 decision to approve the draft. The text mentioned in the Directives and by the appellants is not germane to that decision, which must be taken on the basis of the original DIS text and the actions taken by the BRM on the comments. The provisions of any revised text is not for purposes of further decision by NBs. It's a Catch 22. India says there were too many changes to be able to keep track. Most fast track submissions are already standards, already in use, so changes tend to be typos and minor things. This was a beast of a different color, so it's hard to be sure you even know what changes were made, since most of them were bulk voted. That is India's issue, and ISO/IEC's reaction is hardly responsive to the problem raised. Venezuela Venezuela's issues are deeper. Not only were there a lot of technical issues voted on without adequate discussion at the BRM, Venezuela believes there are too many left undiscussed, never voted on, and still not fixed. You can see an itemized list beginning on page 31. Many issues were not presented at the BRM -- if you remember, that was one of Brazil's complaints, that it tried to speak and was not allowed to -- but of the 1027 items that were allowed and were available for discussion, only 189 were discussed at the BRM. The rest, 838, were decided by group voting. Pages 32 through 35 is an itemization of issues and how they were handled at the BRM, if they were. It's an appalling list, which we are working to get for you as text. Here's one: NB/MB Comment VE-0031 - BRM Question Number 0232 (related) - Covered in BRM? No - Appropriately Addressed? No. Ecma claims that DIS 29500 is compatible with SVG, but errors occur when the reference implementation is replicated.
Here's a comment one can't help but notice, about VE-0029, which also was never discussed at the BRM. Was it appropriately addressed? No, says Venezuela, because "Ecma does not understand the observation." Here's one a bit more somber:
NB/MB COmment VE-0002 - BRM Question Number 142 - Covered in BRM? No - Appropriately addressed? NO. The use of BLOBs (Binary Large Objects) is maintained, without specifying mechanisms for retrieving/displaying them and also leaving the implementation up to the developer without any specification.
That's geek for "No one can use OOXML at the moment but Microsoft, because only it knows how to retrieve/display the proprietary parts." Is it a standard if only one proprietary company can implement it fully, because only they have the key to all the doors, so to speak? Isn't equal access and full specification kind of the point of a standard?
The way matters were handled, Venezuela believes, undermines ISO's reputation, if it approves such a result. And deeper: Venezuela challenges the validity of a process that, from beginning to end, required all parties involved to analyze far too much information in far too little time, involved a BRM that by far did not provide enough time to perform the appointed purpose of that procedure, and for which an arbitrary time limitation was imposed to discuss and resolve a significant number of substantial responses, despite the Directives for not requiring any such [l]imitation as to duration.
The result of DIS 29500 has harmed the reputations of both ISO and the IEC, as well as all they member bodies, and has generated a terrible precedent in which the interest of large multi-national organization, both in favor or against an specific proposal, may dominate the debate instead of the technical discussions necessary to produce the optimal solution on every specific problem. ISO's response, which you can see noted in the yellow boxes: 4. BRM "inconclusive", too short, arbitrarily short, or otherwise incorrectly conducted.
4e. Not correct. Decisions on the comments not discussed during the BRM and proposed dispositions were taken by a process agreed by the BRM itself (29 votes in favour, none against and 2 abstentions.
5. Final report of the BRM not issued.
5e. Not correct. The final report of the BRM was issued on 2008-03-06.
6. "Final" text of ISO/IEC 29500 or ISO/IEC DIS 29500, or "revised FDIS text", not released
6e. Correct but irrelevant. The decision being appealed is the JTC 1 decision to approve the draft. The text mentioned in the Directives and by the appellants is not germane to that decision, which must be taken on the basis of the original DIS text and the actions taken by the BRM on the comments. The provisions of any revised text is not for purposes of further decision by NBs.
8. Document does not follow ISO guidelines for presentation of standards.
8e. Correct but irrelevant. Fast-track submissions need not follow ISO or IEC guidelines for presentation of standards. The corresponding standard must be made to follow the guidelines from its next revision onwards (see JTC 1 Directives, 13).
9. NBs were required to analyze far too much information in far too little time.
9e. A matter for NBs' judgement, which they expressed through their positive or negative vote on the draft.
10. Process followed was incompatible with the principles of consensus, technically-oriented discussions and "redundancy of standards", was dominated by large multinational organization(s), and has harmed the reputations of both ISO and the IEC
10e. Insofar as observation of Statutes, Rules of Procedure, Directives and other rules is concerned, this is not correct. Otherwise it is a matter for NBs' judgement, which they expressed through their positive or negative vote on the draft.
I commented on the ISO/IEC response before, so no need to repeat it. They didn't highlight their answer number 4, but it's clearly a Venezuelan issue, in that they mentioned arbitrary cutoff of discussion time. Why was it all so rushed? It gives me the feel of when someone calls you on the phone to sell you something, and if you ask to read some materials about the offer before making a decision, tells you an immediate yes or no is required. I always say no to offers like that, no matter how good they sound, because if I can't study an offer in detail and get my questions answered, how can I make a good decision? That is likely why the appeals suggest that OOXML be taken off the Fast Track and resubmitted in the regular way, so all the many questions can be discussed and answered.
Update: Erwan has finished the table of comments and their disposition, as submitted by Venezuela, which I have now included as the final item. The pagination is as per the PDF.
*****************************
Rakesh Kacker, IAS
Director General
BUREAU OF INDIAN STANDARDS
[address]
Our Ref: LITD/ADGT/Misc
Mr Alan Bryden
ISO Secretary General
ISO Central Secretariat
[address]
Subject: Appeal from Indian National Body regarding ISO 29500
OOXML
Dear Sir
The Indian National Body (BIS) hereby submits the following
appeal under provision of Clause 11 of JTC 1 directives in
reference to ISO 29500 OOXML:
During the Ballot Resolution Meeting (BRM) on 25-29Feb 2008, a
large number of modifications were decided to be made in the
document. The whole document was restructured and scopes of
different parts were modified.
As per 13.12 of JTC 1 directives it is stated that "In not
more than one month after the ballot resolution group meeting the
SC Secretariat shall distribute the final report of the meeting and
final DIS text in case of acceptance." However, the final text
incorporating the modifications, as envisaged in the BRM is not
available even as on date, thus violating JTC 1 directive.
(13)
All national bodies have the right to appeal in accordance with
Clause 11 of JTC 1 Directives. In the present case, as P-member
national body, it is not possible to exercise our right to appeal
in reference to the content of the final text of the ISO 29500, as
the same has not been made available to national bodies till date.
Thus in terms of the provisions of 11.1.2 of JTC 1 Directives,
there is a clear case for appeal.
We therefore request ISO to extend the permissible time period
for the appeal providing sufficient time for examining the final
text of the standard after the same has been made available to the
national bodies.
Best Regards
(signature)
(Rakesh Kacker)
Director General, Bureau of Indian Standards
cc |
ISO/IEC JTC 1 Chairperson |
|
ISO/IEC JTC 1 Secretariat |
(14)
*******************************
*******************************
FONDONORMA
Fondo para la Normalización
y Certificación de la Calidad
RIF:J000932670
Caracas, 30th May, 2008
Ref N° GN0080-08
Mr Alan Bryden
Secretary-General
Internacional Organization for Standardization ISO
CH-1211 Geneva 20
Switzerland
+ 41 22 733 34 30/ central(AT)iso.org
Appeal from the Venezuelan national body regarding the outcome of the fast-track processing of DIS 29500 Office Open XML.
The national body of Venezuela (FONDONORMA), as a P member of JTC 1, hereby submits an appeal against the outcome of the fast track processing of DIS 29500 Office open XML.
This appeal is made in accordance with Clause 11.1.2; "A P member of JCT 1 or an SC may appeal against any action, or inaction, on the part of JTC 1 or an SC when the P member considers that in such action or inaction:
* questions of principle are involved;
* the contents of a draft may be detrimental to the reputation of IEC or ISO; or
* the point giving rise to objection was not known to JTC 1 or SC during earlier discussions."
Reasons for appeal
1- In our opinion, the procedures used during the discussions of DIS 29500, including the Ballot Resolution Meeting held from 25 to 29 February 2008 are incompatibles with basic principles to the standardization, such as consensus, technically oriented discussions and redundancy of standards, among others.Attachment 1, Item 10
2- It is also our opinion that the proposed standard produced trough this procedures may be detrimental to the reputation of IEC or ISO as an standardization body, because of the clear absence of guidelines for the presentation of ISO standards.
Attachment 1, Item 8
3- We believe that the use of the fast track procedures was inadequate to the length and technical complexity of the DIS 29500 proposal, which added to the lack of technical, objective discussion, and the fact that procedures used during the Ballot Resolution Meeting held from 25 to 29 February 2008 leaved unattended too many standing technical issues in the proposal, resulted in a standard proposal that lacks the quality that usually describes the body of work of ISO.
Attachment 1, Item 9
4- We also raise to your consideration the fact that up to date of writing, neither the final report of the BRM meeting or the revised FDIS text has been circulated by the SC Secretariat, in clear contradiction with clause 13.12, last bullet point: "In not more than one month after the ballot resolution group meeting the SC Secretariat shall distribute the final report of the meeting and fnal DIS text in case of acceptance." Attachment 1, Items 5, 6
Conclusion
Venezuela challenges the validity of a process that, from beginning to end, required all parties involved to analyze far too much information in far too little time, involved a BRM that by far did not provide enough time to perform the appointed purpose of that procedure, and for which an arbitrary time limitation was imposed to discuss and resolve a significant number of substantial responses, despite the Directives for not requiring any such [l]imitation as to duration.
The result of DIS 29500 has harmed the reputations of both ISO and the IEC, as well as all they member bodies, and has generated a terrible precedent in which the interest of large multi-national organization, both in favor or against an specific proposal, may dominate the debate instead of the technical discussions necessary to produce the optimal solution on every specific problem.
Best regards
Maria Teresa Saccucci
Standardization Manager
FONDONORMA
Venezuela
cc |
ISO TMB Secretary (Mr Mike Smith) |
| IEC SMB Secretary (Mr Jack Sheldon) |
| ISO/IEC JTC 1 Chairman (Mr Scott Jameson scott.jameson (AT) hp.com) |
| ISO/IEC JTC 1 Secretariat (Ms Lisa Rajchel lrajchel (AT) ansi.org) |
[Fax]
Annex 1 – BRM Vote Breakdown Table
Total of responses available for discussion
|
Total of responses addressed at the BRM
|
Total of responses decided by group-voting
|
1027 - 100% |
189 – 18,4% |
838 – 81,6 % |
(31)
Annex 2 – Standing Issues as presented by VE
NB/MB Comment |
BRM Question Number |
Covered in BRM? |
Appropiately Addressed? |
VE-0001 |
102 |
YES |
NO. The mechanisms persist in an annex when they should be entirely removed. Also, the use of MD2 and MD4 (weak cryptographic algorithms) is suggested.
|
VE-0002 |
142 |
NO |
NO. The use of BLOBs (Binary Large Objects) is mantained, without specifying mechanisms for retrieving/displaying them and also leaving the implementation up to the developer without any specifications.
|
VE-0007 |
0073 |
NO |
NO. Pseudo-code is not specified in the standard. This was not addressed at the BRM
|
VE-0008 |
0035 |
NO |
NO. Complex configurations are moved and rewritten in an annex and the necessary documentation has not been delivered. |
VE-0009 |
0035 |
NO |
NO. Complex configurations are moved and rewritten in an annex and the necessary documentation has not been delivered. |
VE-0010 |
|
YES |
YES |
VE-0011 |
0018 |
NO |
NO. The changes made at the BRM keep the old style date format as the default. 1900 should not be handled as a leap year. |
VE-0012 |
0035 |
NO |
NO. Complex configurations are moved and rewritten in an annex and the necessary documentation has not been delivered. |
|
VE-0013 |
0092 |
YES |
NO. New XML types are defined as to eliminate VML, however, there's no text that explains the new XML types or their meaning. VML is moved to an annex when it should be entirely removed. |
VE-0014 |
0092 |
YES |
NO. New XML types are defined as to eliminate VML, however, there's no text that explains the new XML types or their meaning. VML is moved to an annex when it should be entirely removed. |
VE-0015 |
|
YES |
YES |
VE-0016 |
0101 (related) |
NO |
NO. All the render parameters are left to the application
side implementation. |
VE-0017 |
102 |
YES |
NO. The mechanisms persist in an annex when they |
(32)
|
|
|
|
should be entirely removed. Also, the use of MD2 and MD4 (weak cryptographic algorithms) is suggested. |
VE-0018 |
|
YES |
YES |
VE-0019 |
|
YES |
YES |
VE-0020 |
|
YES |
YES |
VE-0021 |
0099 |
YES |
NO. Partially addressed. Proposes a dual mode solution, when it should propose a universal solution. |
VE-0022 |
|
YES |
YES |
VE-0023 |
0099 |
YES |
NO. Partially addressed. Proposes a dual mode solution, when it should propose a universal solution. |
VE-0024 |
|
YES |
YES |
VE-0025 |
|
YES |
YES |
VE-0026 |
|
NO |
NO. Ecma claims that this is against the proposal objectives. |
VE-0027 |
|
YES |
YES |
VE-0028 |
|
NO |
NO. Ecma claims that this is against the proposal objectives. |
VE-0029 |
|
NO |
NO. Ecma does not understand the observation. |
VE-0030 |
|
YES |
YES |
VE-0031 |
0232 (related) |
NO |
NO. Ecma claims that DIS 29500 is compatible with
SVG, but errors occur when the reference implementation is replicated. |
VE-0032 |
|
YES |
YES |
VE-0033 |
|
YES |
YES |
VE-0034 |
|
YES |
YES |
VE-0035 |
0016 |
YES |
NO. The proposed solution partially changes the text that defines ST_LangCode and keeps the same underlying failure of having two ways of identifiying languages instead of using ISO 639 |
VE-0036 |
0016 |
YES |
NO. The proposed solution partially changes the text that defines ST_LangCode and keeps the same underlying failure of having two ways of identifiying languages instead of using ISO 639 |
VE-0037 |
|
YES |
YES |
VE-0038 |
0016 |
YES |
NO. The proposed solution partially changes the text that defines ST_LangCode and keeps the same underlying failure of having two ways of identifiying languages instead of using ISO 639 |
VE-0039 |
|
YES |
YES |
(33)
|
VE-0040 |
|
YES |
YES |
VE-0041 |
|
YES |
YES |
VE-0042 |
|
NO |
NO. The XSLT standart is allowed as a customization and it's not default. |
VE-0043 |
|
YES |
YES |
VE-0044 |
|
YES |
YES |
VE-0045 |
|
YES |
YES |
VE-0046 |
|
YES |
YES |
VE-0047 |
|
YES |
YES |
VE-0048 |
|
YES |
YES |
VE-0049 |
|
YES |
YES |
VE-0050 |
|
YES |
YES. Comment: OOXML uses a custom type to store content that goes against the XML standard. |
VE-0051 |
|
YES |
YES |
VE-0052 |
|
YES |
YES |
VE-0053 |
|
YES |
YES. Comment: OOXML uses a custom type to store content that goes against the XML standard. |
VE-0054 |
102 |
YES |
NO. The mechanisms persist in an annex when they should be entirely removed. Also, the use of MD2 and MD4 (weak cryptographic algorithms) is suggested. |
VE-0055 |
102 |
YES |
NO. The mechanisms persist in an annex when they should be entirely removed. Also, the use of MD2 and MD4 (weak cryptographic algorithms) is suggested. |
VE-0056 |
102 |
YES |
NO. The mechanisms persist in an annex when they should be entirely removed. Also, the use of MD2 and MD4 (weak cryptographic algorithms) is suggested. |
VE-0057 |
0341 |
NO |
NO. The paper size is stored as a code instead of using an standard format |
VE-0058 |
0341 |
NO |
NO. The paper size is stored as a code instead of using an standard format |
VE-0059 |
|
YES |
YES |
VE-0060 |
0018 |
NO |
NO. The changes made at the BRM keep the old style date format as the default. 1900 should not be handled as a leap year. |
VE-0061 |
|
YES |
YES |
VE-0062 |
|
YES |
YES |
VE-0063 |
|
YES |
YES |
VE-0064 |
|
YES |
YES |
(34)
|
VE-0065 |
|
YES |
YES |
VE-0066 |
|
YES |
YES |
VE-0067 |
|
YES |
YES |
VE-0068 |
|
NO |
NO. These foreign XML entities are kept, despite the compatibility issues. |
VE-0069 |
|
YES |
YES |
VE-0070 |
|
YES |
YES. Comment: The technical issues specified by the National Body do not represent all the interoperativity problems between operating systems of this proposal. A big vendor dependency issue persists and the lack of practical implementations for multiple environments. |
VE-0071 |
|
YES |
YES. Comment: The technical issues specified by the National Body do not represent all the interoperativity problems between operating systems of this proposal. A big vendor dependency issue persists and the lack of practical implementations for multiple environments. |
VE-0072 |
|
YES |
YES. Comment: The technical issues specified by the National Body do not represent all the interoperativity problems between operating systems of this proposal. A big vendor dependency issue persists and the lack of practical implementations for multiple environments. |
VE-0073 |
0092 |
YES |
NO. New XML types are defined as to eliminate VML, however, there's no text that explains the new XML types or their meaning. VML is moved to an annex when it should be entirely removed. |
(35)
|