From owner-incits-v1@incits-v1.org Thu Jul 12 14:34:14 2007 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Date: Thu, 12 Jul 2007 17:31:32 -0400 From: Frank Farance Subject: Re: INCITS-V1: Two types of diapprove with comments In-reply-to: <4696613A.5010306@durusau.net> Sender: owner-incits-v1@incits-v1.org X-Sender: frankscan@127.0.0.1 To: incits-v1@incits-v1.org Reply-to: incits-v1@incits-v1.org X-PMX-Version: 5.2.0.264296 At 13:13 2007-07-12 -0400, Patrick Durusau wrote: > Rob, > > > > > My recommendation is to vote "No with comments", but not to check the > > "Acceptance of specified technical modifications will change our vote > > to approval" option. Why? Because I do not believe the Ecma's or our > > review has been sufficient to find anything but a small portion of the > > grave errors in this specification. I've done my best to write down > > the problems I've found, as have others, and we've all worked hard to > > discuss what has been reported. So this is not for lack of effort on > > our part. But it is also a fact that we have not been able to conduct > > anything close to a thorough review. I can open to almost any page of > > this specification and find serious ambiguities, undefined behaviors > > and outright errors. I've reported what I could, based on the time > > permitted us, but this is just the tip of the iceberg. Merely fixing > > the reported errors will still leave an enormous number of problems in > > the standard. I'm operating on the cockroach theory of quality here. > > If you see a few, there are certainly many. Based on the defects > > I've seen and reported so far, I am convinced that this DIS needs to > > be returned for comprehensive review and editing within Ecma, after > > which it may be resubmitted for JTC1 NB review. > > > > OOXML, as we received it, was not ready for a DIS ballot, and should > > never have been submitted to JTC1 in this state. > > > I am sure that everyone, including members of TC 45 appreciate the hard > work you have done in reviewing DIS 29500. > > But, on the other hand, comments about the quality of material not > reviewed aren't helpful. Moreover, I haven't seen any signal from TC 45 > that they are simply going to correct only issues that are pointed out > to them. I am fairly sure they have a list of issues they have found > internally before the review by NBs and they want to correct those as well. To be precise, the ballot resolution meeting corresponds to the changes identified in the ballot comments. So assuming that NBs accept all the suggested comments, then the Project Editor *only* makes those changes to the document. While the Project Editor may correct inconsistencies in the document (e.g., a comment to change "foo" to "bar" in Clause X, might also imply the same change in Clause Y to make the document consistent), there won't be any gratuitous changes in the document. In other words, the Project Editor is not free to make other changes. Or said differently, this is our only shot to offer changes to the document before it become a standard. > I don't doubt that even after several more months of hard work by TC 45 > and aided by NBs from around the world that there are going to be > problems remaining in DIS 29500. If you have been watching the > discussion list on OpenDocument you will notice that suggestions have > been made for corrections there as well. Unless the corrections arrive via ballot comments and are discussed at the BRM, those changes won't get made. > I think I understand your position but I also think that simply asking > TC 45 members, one of who is the editor of DIS 29500, if they are going > to correct errors and problems with DIS 29500 that aren't the subject of > NB comments (which I am sure they are) would be the better approach. > > I don't mean to discourage anyone from posting any opinions concerning > any issue but I do think that some ways of discussing issues are more > productive than others. Finally, I think people misunderstand TC45's role. ECMA submitted the document. The document belongs to ISO. ECMA *cannot* withdraw the document if they don't like our changes. Changes will be determined by the wishes of NBs, not ECMA (although they are free to give advice). Future releases of the document will be determined by ISO/IEC, i.e., NB votes, and ISO/IEC maintenance processes (Amendments, Technical Corrigenda, Defect Reports, Revisions, etc.). In other words, the only difference between a standard developed by the "normal" process and this standard is: we are starting at the last stage. But thereafter, NBs (via SC34) update and maintain the document via the normal mechanism, e.g., we don't go back to ECMA to request changes. ECMA is welcome to provide suggestions on improvements, but they have no say in the process/decisions, i.e., liaisons are not permitted to vote. -FF ______________________________________________________________________ Frank Farance, Farance Inc. T: +1 212 486 4700 F: +1 212 759 1605 mailto:frank@farance.com http://farance.com Standards/Products/Services for Information/Communication Technologies