From jon.bosak@Sun.COM Thu May 17 16:00:39 2007 Date: Thu, 17 May 2007 16:00:36 -0700 (PDT) From: jon.bosak@Sun.COM Subject: Response to Rex Jaeschke's message of 12 May In-reply-to: <019901c794c0$bfeefa10$3fccee30$@com> To: rex@RexJaeschke.com, Dave.Welsh@microsoft.com, patrick@durusau.net, frank@farance.com, eduardo.gutentag@Sun.COM, lprice@ix.netcom.com, Doug.Mahugh@microsoft.com, steve.carton@retrievalsystems.com, jerry.smith@disa.mil, ndw@nwalsh.com, Richard.Barber@mindjet.com, robert_weir@us.ibm.com, Leonard.Levine@disa.mil, timothy@schoechle.org, ktrainor@ligent.net X-PMX-Version: 5.2.0.264296 X-Authentication-warning: jurassic-x4600.sfbay.sun.com: bosak set sender to jon.bosak@sun.com using -f Since many V1 members were not on the call Monday, I thought I'd better go on record with my responses to some points expressed in Rex's message of 12 May. "I see the main task of V1 as reporting editorial and technical errors that impede or prohibit implementation of the specification." I do not accept this as a statement of the criteria I'm going to use in judging whether the DIS is acceptable as an ISO standard, which is the question before us. I've been in V1 and in the group now known as SC34 since 1995, and I have my own ideas of what constitutes acceptable ANSI and ISO standards in this area. With regard to Rex's specific recommendations: "1. Members review whichever parts and clauses of the specification they see fit." I agree. "2. Members only report editorial and technical errors that impede or prohibit implementation of the specification." I cannot accept this restriction. There are some larger issues at play here, and those issues need to be discussed. "3. Any member submitting an error must explain the problem clearly enough for it to be addressed at any ballot resolution meeting, and should do their best at outlining possible solutions." I agree to do my best to outline possible solutions if I can see any, but I do not intend to make extraordinary efforts to propose solutions to faults that appear to me to be irreparable. I trust that the proponents of the DIS will provide that input. "4. All comments should be submitted to V1 using the JTC 1 comment form." I'm very sensitive to the process mechanics involved here, and I'll certainly do my best to accommodate any form the chair deems most expeditious. And I don't mind logging comment status using a form. But there are issues the statement of which may not fit the form. "5. Information shared with the public at large be restricted to generic status reports, and not cover specific issues or positions." I am a strong supporter of public access to standards work. I've worked for several years now running a fairly significant OASIS standards committee with a completely open process, and it's done us nothing but good. V1 has never operated as a smoke-filled room, and I see no reason why it should start now. Hiding our work from the public cannot possibly foster public acceptance of the result, and doing so would deny us the benefit of much expert input. Personally, I don't like wikis, but Rob Weir's suggestion to make a wiki publicly visible but not publicly modifiable seems to me a good one, and this principle can be extended to a bugzilla application such as the one that Frank Farance kindly offered to set up for this work. Regardless of what the group decides in this respect, however, I want it clearly understood that I personally intend to share with the public anything that I think it in the public interest for the public to know -- including anything exchanged via email in this group. The standards promulgated by the agencies involved in this work can and sometimes do have the force of law. The public good requires that the process by which such standards are created be open to view. If people believe that what they have to say in this forum won't stand the light of day, they shouldn't say it. In the interest of everyone involved, therefore, I think it would be wise of the group to expose the complete record of its discussions in order to guarantee fair and complete reporting unfiltered by anyone's particular bias. Jon ================================================================== Date: Sat, 12 May 2007 14:09:54 -0400 From: Rex Jaeschke Dear V1 Members, I'm writing the following in response to Patrick's recent posting about the process to be used to deal with the OpenXML DIS 29500 Fast Track. We'll be discussing this topic on next Monday's phone call. Introduction As many of us know from experience, making a software specification of non-trivial size and complexity be perfect is extremely difficult and time consuming. And I think we all agree that DIS 29500 is of non-trivial size and complexity. The pragmatic approach then is to ask, "Is the DIS 29500 specification good enough for the current and projected needs of business and industry? And if defects that materially affect those needs are found, is there a good enough process in place to fix them?" Hindsight is the most exacting science. Yes, if we were starting from scratch, we'd all like to improve any standard on which we've worked. However, in any standard that attempts to consolidate prior art, as does DIS 29500, I hope we are beyond the point of trying to make it perfect for perfections own sake. As such, with respect to DIS 29500, I see the main task of V1 as reporting editorial and technical errors that impede or prohibit implementation of the specification. And since the submitter of such an error must explain the problem clearly enough for it to be addressed at any ballot resolution meeting, they are also in the best position to outline possible solutions. Indeed, I believe they have an obligation to do so lest the error be considered purely academic. Document Review I see two approaches to performing a review of the specification: 1. Let members "do their own thing". 2. Break down the specification into "bite-size" chunks and assign each to one or more members. The first option allows members to spend their time on the topics that interest them, thereby allowing them to justify their investment. And while it might result in overlap among reviewers, given the size of the specification, and the time available, that is unlikely. In any event, as editor, I view multiple independent reviews of Part 1 and the intro material for each ML in part 4 to be most welcome. The second option might provide good and thorough coverage, but requires serious organization and time. It also requires members to agree to work on subject matter that might not interest them or be relevant to their reasons for participating in V1. In any event, there are obvious ways in which to break down the specification. I favor the first option. Recording of Issues I've managed four lots of comment submissions for Fast-Track projects, and the best approach I've found is described below. Ultimately, we'll have to submit any comments using the JTC 1-sanctioned comment form (see attached). As such, I believe that we should use that form throughout our entire issue-gathering process. Specifically, anyone who submits a comment (and, hopefully, a proposed resolution) does so using this form. Then issues get added to the master list (maintained by Patrick, perhaps?), which also uses that form. Patrick can assign each issue on the master list a sequential issue number. Periodically, he'd circulate the current master issues list, so we're all in sync. We can use (the otherwise unused) column 7 to keep an audit trail of the issue: Add a date stamp for when the issue was raised, then each time the issue has had non-trivial decisions, along with details of the discussion. We can color cells (or whole rows) in the table to highlight issues and attributes, such as "pending", "closed", and "rejected". We can even add new rows/columns to the table for our own internal purposes. At the end of our deliberations, we simply clear column 7, delete any housekeeping rows/columns we've added, delete those rows pertaining to issues that are not to be forwarded, and remove any other extraneous notation we may have added. The primary advantage of this approach is that we always see each issue presented in the manner in which we have to submit it. My experience has shown that if we don't use this kind of approach, we'll submit comments to V1 in different forms using different tools, and, at the last minute, when the final set is moved to the required format, we'll have had little or no experience at looking at them in that form, so won't be as confident of the fidelity of the translation that went on. Public Access to Committee Work Patrick asked, ". whether we want to have a wiki for which there is read access by the general public but write access only by V1 members, for the discussion of issues?" An INCITS TC's primary obligation is to follow the wishes of its voting membership within the rules. Membership of a TC is open to anyone who can afford the fee and the time to participate, which allows any interested/affected party to participate. That's the value-added proposition of being a member; you get to sit at the table! A TC has no obligation to the general public at large although one can construct rationale for keeping them "informed". (The INCITS, JTC 1, and Ecma committees on which I have been participating do that via periodic news releases or summary documents on the public part of their websites. None of them makes documents on "in-progress" topics available outside the committee.) What does V1 do in this regard for its other projects? Are we being consistent? With respect to making issues public once V1 has formed an official position on them, I believe that nothing is official until the final vote is taken. Each voting member reserves the right to change their mind until the end (note the non-trivial percentage of undecideds in polls leading up to elections here in the U.S.). Publishing a 5/4 vote on an issue one week and then publishing a revised vote of 4/5 on that same issue two weeks later, doesn't help the public, and probably confuses them, yet still gives rise to media/bloggers' distorting the real situation. Summary Here then are my recommendations: 1. Members review whichever parts and clauses of the specification they see fit. 2. Members only report editorial and technical errors that impede or prohibit implementation of the specification. 3. Any member submitting an error must explain the problem clearly enough for it to be addressed at any ballot resolution meeting, and should do their best at outlining possible solutions. 4. All comments should be submitted to V1 using the JTC 1 comment form. 5. Information shared with the public at large be restricted to generic status reports, and not cover specific issues or positions. Rex ---------------- Rex Jaeschke http://www.RexJaeschke.com Skype: RexJaeschke 2051 Swans Neck Way, Reston, VA, 20191-4023, USA Phone: +1 703 860-0091, Fax: +1 703 860-3008