Subject: RE: Response to Rex Jaeschke's message of 12 May

From: Steve Carton <[email-masked]>
Date: Fri, 18 May 2007 10:36:36 -0400

I would like to second Jon's comments below. Especially with regard to
public access. I firmly believe that what we are doing here should be
able to stand the scrutiny of the general public.

Steve Carton 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, May 17, 2007 7:01 PM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; Steve Carton; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Response to Rex Jaeschke's message of 12 May

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 <[email-masked]>

   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