From owner-incits-v1@incits-v1.org Mon Jul 2 05:26:19 2007 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Date: Mon, 02 Jul 2007 07:20:05 -0700 From: Patrick Durusau Subject: INCITS-V1: The Nature of disapprove with suggested changes Sender: owner-incits-v1@incits-v1.org To: Incits-V1 Reply-to: incits-v1@incits-v1.org X-PMX-Version: 5.2.0.264296 X-ASG-Debug-ID: 1183375212-2bbf00270000-E618Iy X-Barracuda-URL: http://10.10.100.8:8000/cgi-bin/mark.cgi X-Barracuda-Connect: unknown[66.110.197.207] X-Barracuda-Start-Time: 1183375212 X-ASG-Whitelist: Client X-ASG-Orig-Subj: The Nature of disapprove with suggested changes X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at insimail.com Greetings! One of the positions that is possible for V1 is to disapprove with suggested wording/changes that would change its vote to approve. But as Joe Messina observed at our face to face meeting, there are no perfect standards and there will always be future versions of any particular standard. Having edited more than one standard I can second Joe's observation. But even if there are no perfect standards and there is always "next time," are there problems that would rise to the level of requiring changes in a standard before it can advance the first time? That would be a much narrower set of problems than simply inconsistent element naming (perhaps a next time issue) for example. Let me give an example of an issue, a fictional one, that illustrates what I think would be a disapprove type problem. Assume that one part of a proposed standard said: "All documents SHALL use Unicode (ISO/IEC 10646) character encodings in UTF-8." Another part of the standard says: "All documents SHALL use Unicode (ISO/IEC 10646) character encodings in UTF-16." (For those unfamiliar with Unicode, those are two of the permitted character encodings for the use of Unicode.) I would argue that such a standard should be disapproved and asked to pick one encoding or the other, or to permit conformance to the standard by using either one. My reasoning would be that although the standard is clear, it is also clear that an application cannot conform to the standard as it has two mutually contradictory requirements. On one hand it says shall use UTF-8 and on the other hand, shall use UTF-16. That is an easy case because most Unicode software can read either one and the problem could be solved by putting them in the alternative or even simply requiring the use of Unicode and leave the choice of the encoding up to the application. I haven't found a lot of commentary on the grounds for disapprove with suggested changes but my personal opinion is that the problems would have to be ones that strike at the very nature of being a standard. For example, if critical information is not defined or defined in such a way that multiple (and incompatible) interpretations are possible that will lead to a lack of interoperability, or if the requirements are not clear, that is the use of "shall" and other terms are not consistent such that anyone reading the standard will come away with the same set of requirements, etc., then I think the standard should get what is called "conditional approval", that is a no with but if X is fixed, then the vote is yes. My primary concerns are with people coming away from any standard, including DIS 29500, with a common understanding of what is required of them in order to implement the standard. Noting that under or non-definition can cause the same problems as failing to properly define requirements. Editorial problems are annoying and should be fixed as soon as possible but I think they are in a different class than problems that prevent interoperability of implementations of the standard per se. Opinions are likely to differ on the nature of issues that merit a disapprove with suggested changes but I thought it would be useful to offer a starting point for such a discussion. I hope everyone is having a great holiday! Patrick -- Patrick Durusau patrick@durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Acting Convener, JTC 1/SC 34/WG 3 (Topic Maps) Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Co-Editor, OpenDocument Format (OASIS, ISO/IEC 26300)