From owner-incits-v1@incits-v1.org Wed Jul 11 16:33:57 2007 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Date: Wed, 11 Jul 2007 19:31:43 -0400 From: Patrick Durusau Subject: INCITS-V1: Progressing DIS 29500 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: 1184196734-38d400570000-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: 1184196734 X-ASG-Whitelist: Client X-ASG-Orig-Subj: Progressing DIS 29500 X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at insimail.com Greetings! With my chair hat firmly on the table I wanted to make some comments about defining "progressing DIS 29500" as I understand it. In my view, "progressing DIS 29500" means that the text approved as an IS has a variety of substantive technical errors (excepting editorial errors that can't be reached within a reasonable time period) corrected. How would we get to that state? Well, we know that the ballot closes in early September and it is unlikely that any ballot resolution meeting is going to be scheduled before the end of the year. While I greatly enjoy the company of each and every one of you, I don't really relish the idea of spending the Christmas holidays in a ballot resolution meeting. So, how would we spend those four months or more months? We could simply watch the drive-by bloggings on the comments, which will by that point be public. Or, we, along with TC 45 and other NBs around the world, who represent some of the finest minds in markup languages, could turn our attention to devising solutions to issues in DIS 29500 so that the text proposed in response to comments at a BRM fixes the technical issues in the current proposal. That is to say that largely on the same timetable that exists for DIS 29500 "as written" that a truly collaborative effort could result is a DIS 29500 "as corrected" which would be to the benefit of all concerned. Granted it is going to take a lot of effort, which the members of TC 45 have already contributed to get to this point, but I see the alternatives as follows: DIS 29500 "as written" DIS 29500 "as corrected" emerging at approximately the same time. To my mind, the second is more deserving of the phrase "progressing DIS 29500" than the former. Lest you think I am being overly optimistic, recall that Tom Ngo said in Washington that TC 45 has already discussed the possibility of refactoring DIS 29500 into "parts" as the term is used in ISO. And I don't think any of us want to see an ISO standard that doesn't properly define XML Schema datatypes or fails to properly define any number of other easily corrected items before it issues as an IS. I think the key to making that sort of progress is a general recognition of the hard work that TC 45 has done already and a reciprocal recognition by TC 45 that suggestions for corrections are well intentioned and meant to make DIS 29500 a better proposal and not to delay or impede its progress. I am not so unaware of the by play surrounding DIS 29500 to think for a moment that this is purely a technical issue. However, I do think this is a case where the hard core technical people can blunt the political and other agendas of others by banding together to make DIS 29500 the best possible proposal (that is with corrections) before it becomes an IS. I am currently an editor of four or five standards in at least three different fields and have no illusion that any version of DIS 29500 is going to be completely problem free. If it were, then we would be putting our committees out of business. ;-) Seriously, no standard is perfect but that is no excuse for pushing a proposal that has admitted correctable problems forward without first correcting the technical issues as best we can. Let me give you an example of an error that could go uncorrected in the corrected version of DIS 29500. Take my comment on element names. I really think that is a problem but it is an aesthetic one. Granted once it becomes an IS we are going to be stuck with inconsistent naming conventions but (hopefully) most users are never going to see that sort of thing anyway. On the other hand, not having meaningful conformance clauses for a refactored DIS 29500 prevents the goal of interoperability that is one of the primary goals of ISO standards. How is my DrawingML application to distinguish itself from any one of hundreds if not thousands of other DIS 29500 applications, all of which claim to conform to DIS 29500? The answer is as written it can't. Nor can I guarantee that it will interoperate with other DrawingML applications. I don't mean to suggest that my personal views of those two issues (or any others that I have mentioned) will actually prevail but I had to use examples that were relevant to the proposal in front of us. I am willing to work within V1, with TC 45 members, TC 45 itself, or anyone else, with a view of producing a corrected DIS 29500 largely on the same schedule as it would face in any event. How about you? I hope everyone is having a great day! Patrick PS: A quick story to illustrate my point about cooperation: Two friends were riding through an ancient battle field between two countries. The first one asked his friend who was from one of the warring countries, "Why?" To which the second friend replied: "At first we fought for glory and honor. Then we fought for revenge for fallen friends and loved ones. Finally, we fought because we had forgotten how to stop." I think it is time to remember how to stop fighting and to start cooperating. -- 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)