From robert_weir@us.ibm.com Sat May 19 12:52:07 2007 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_At0KFVry4U+ej5bQCWiOmg)" Date: Sat, 19 May 2007 15:52:12 -0400 From: robert_weir@us.ibm.com Subject: RE: Response to Rex Jaeschke's message of 12 May In-reply-to: To: Steve Carton , Dave.Welsh@microsoft.com, Doug.Mahugh@microsoft.com, eduardo.gutentag@Sun.COM, frank@farance.com, jerry.smith@disa.mil, jon.bosak@Sun.COM, ktrainor@ligent.net, Leonard.Levine@disa.mil, lprice@ix.netcom.com, ndw@nwalsh.com, patrick@durusau.net, rex@RexJaeschke.com, Richard.Barber@mindjet.com, timothy@schoechle.org X-MIMETrack: Serialize by Router on WTFMAIL03/WTF/M/Lotus(Release 6.5.6FP1|April 24, 2007) at 05/19/2007 03:52:13 PM, Serialize complete at 05/19/2007 03:52:13 PM X-PMX-Version: 5.2.0.264296 This is a multipart message in MIME format. --Boundary_(ID_At0KFVry4U+ej5bQCWiOmg) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT On the subject of public scrutiny, I'd note the initiatives of two other NB's looking at this ballot: BSI has a Wiki, read-only to the public, where committee comments are being registered; http://www.xmlopen.org/ooxml-wiki/index.php/Terms-of-reference SCC has put out a press release soliciting public comments on OOXML: http://www.scc.ca/en/news_events/pr/pr_details_220.shtml INCITS certainly has a public comment facility as well: http://www.incits.org/prsweb_all.htm , though I'm not aware of them having a Wiki. The question came up as well (maybe from Doug?) on why we didn't discuss these issues during the contradiction period. My understanding is that was handled entirely by the INCITS Executive Board without consulting V1. For what it is worth, the public comments received during that stage are posted here: http://www.incits.org/DIS29500/DIS29500.htm -Rob "Steve Carton" wrote on 05/18/2007 10:36:36 AM: > 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: jon.bosak@sun.com [mailto:jon.bosak@sun.com] > Sent: Thursday, May 17, 2007 7:01 PM > 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; 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 > 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 > > 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 --Boundary_(ID_At0KFVry4U+ej5bQCWiOmg) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT
On the subject of public scrutiny, I'd note the initiatives of two other NB's looking at this ballot:

BSI has a Wiki, read-only to the public, where committee comments are being registered;  http://www.xmlopen.org/ooxml-wiki/index.php/Terms-of-reference

SCC has put out a press release soliciting public comments on OOXML:  http://www.scc.ca/en/news_events/pr/pr_details_220.shtml

INCITS certainly has a public comment facility as well:  http://www.incits.org/prsweb_all.htm , though I'm not aware of them having a Wiki.

The question came up as well (maybe from Doug?) on why we didn't discuss these issues during the contradiction period.  My understanding is that was handled entirely by the INCITS Executive Board without consulting V1.  For what it is worth, the public comments received during that stage are posted here:  http://www.incits.org/DIS29500/DIS29500.htm

-Rob

"Steve Carton" <steve.carton@retrievalsystems.com> wrote on 05/18/2007 10:36:36 AM:

> 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: jon.bosak@sun.com [mailto:jon.bosak@sun.com]
> Sent: Thursday, May 17, 2007 7:01 PM
> 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; 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
> 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 <rex@RexJaeschke.com>
>
>    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
--Boundary_(ID_At0KFVry4U+ej5bQCWiOmg)--