decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.


To read comments to this article, go here
The ISO Document: India's and Venezuela's Appeals, as text - Updated with comments chart
Monday, July 14 2008 @ 01:30 PM EDT

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)


  View Printable Version


Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )