From robert_weir@us.ibm.com Sun May 13 09:50:28 2007
MIME-Version: 1.0
Content-type: multipart/alternative;
 boundary="Boundary_(ID_VMFxj6P3PQhqUnN5UdfKTw)"
Date: Sun, 13 May 2007 12:50:11 -0400
From: robert_weir@us.ibm.com
Subject: RE: May 14th Meeting Notice and Agenda (and future meetings)
In-reply-to: <019901c794c0$bfeefa10$3fccee30$@com>
To: Rex Jaeschke <rex@RexJaeschke.com>
Cc: "'Dave Welsh'" <Dave.Welsh@microsoft.com>,
        "'Doug Mahugh'" <Doug.Mahugh@microsoft.com>,
        "'Frank Farance'" <frank@farance.com>,
        "'Jerry Smith'" <jerry.smith@disa.mil>,
        "'Jon Bosak'" <jon.bosak@sun.com>,
        "'Kevin Trainor'" <ktrainor@ligent.net>,
        "'Levine, Leonard F CIV DISA GES-E'" <Leonard.Levine@disa.mil>,
        "'Price, Lynne'" <lprice@ix.netcom.com>,
        "'Norm Walsh'" <ndw@nwalsh.com>, patrick@durusau.net,
        "'Richard Barber'" <Richard.Barber@mindjet.com>,
        "'Steve Carton'" <steve.carton@retrievalsystems.com>,
        "'Tim Schoechle'" <timothy@schoechle.org>
X-MIMETrack: Serialize by Router on WTFMAIL03/WTF/M/Lotus(Release
 6.5.5FP3|February 7, 2007) at 05/13/2007 12:50:12 PM,
	Serialize complete at 05/13/2007 12:50:12 PM
X-PMX-Version: 5.2.0.264296

This is a multipart message in MIME format.

--Boundary_(ID_VMFxj6P3PQhqUnN5UdfKTw)
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7BIT

+1 on using the ISO comment template.  This will make less work for us all 
in the long run if we track the issues from the start in the form we'll 
ultimately need to submit them to JTC1 in.

I'd like to discuss a bit more the public visibility side of this. 
Although the public should not be actively deliberating with us, I see no 
reason why, in a subject of public interest, they should not be kept 
apprised of our progress.  I'd point to what the BSI is doing with their 
comments as one model for how to accomplish this.  They are maintaining a 
Wiki to track the issues, which the public can view, but not modify.  The 
chair of their review panel, Alex Brown, whom most of us know, has more 
details here:  http://adjb.net/index.php?entry=entry070512-141206   I note 
that they are reporting the issues raised, but not the votes on the 
issues.  That seems like a fair compromise that addresses your point that 
no vote is final until the end.

I'd respectfully disagree that we limit ourselves only to issues that 
would "impede or prohibit implementation of the specification". Certainly, 
in a process of triage we will naturally bring these issues to the 
forefront, but I expect an ISO Standard to exhibit positive aspects which 
encourage interoperability, and not merely the absence of flaws that 
prohibit implementation.  The BSI panel set its goal as: "We expect a 
precise, clear, and complete description of OOXML, which accords with JTC 
1 directives and which properly services its design objectives and the 
likely needs of international users".  V1 should ask for no less. 
Remember, this 5-month review itself is part of the "process to in place 
to fix them [defects]", so let's use it for that purpose.

Regards,

-Rob
___________________________

Rob Weir
Software Architect
Workplace, Portal and Collaboration Software
IBM Software Group

email: robert_weir@us.ibm.com
phone: 1-978-399-7122
blog: http://www.robweir.com/blog/

"Rex Jaeschke" <rex@RexJaeschke.com> wrote on 05/12/2007 02:09:54 PM:

> 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
> <<...>> [attachment "ISO Comment Template.doc" deleted by Robert 
> Weir/Cambridge/IBM] 

--Boundary_(ID_VMFxj6P3PQhqUnN5UdfKTw)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: 7BIT


<br><font size=2 face="sans-serif">+1 on using the ISO comment template.
&nbsp;This will make less work for us all in the long run if we track the
issues from the start in the form we'll ultimately need to submit them
to JTC1 in.</font>
<br>
<br><font size=2 face="sans-serif">I'd like to discuss a bit more the public
visibility side of this. &nbsp;Although the public should not be actively
deliberating with us, I see no reason why, in a subject of public interest,
they should not be kept apprised of our progress. &nbsp;I'd point to what
the BSI is doing with their comments as one model for how to accomplish
this. &nbsp;They are maintaining a Wiki to track the issues, which the
public can view, but not modify. &nbsp;The chair of their review panel,
Alex Brown, whom most of us know, has more details here: &nbsp;http://adjb.net/index.php?entry=entry070512-141206
&nbsp; I note that they are reporting the issues raised, but not the votes
on the issues. &nbsp;That seems like a fair compromise that addresses your
point that no vote is final until the end.</font>
<br>
<br><font size=2 face="sans-serif">I'd respectfully disagree that we limit
ourselves only to issues that would &quot;impede or prohibit implementation
of the specification&quot;. &nbsp;Certainly, in a process of triage we
will naturally bring these issues to the forefront, but I expect an ISO
Standard to exhibit positive aspects which encourage interoperability,
and not merely the absence of flaws that prohibit implementation. &nbsp;The
BSI panel set its goal as: &quot;We expect a precise, clear, and complete
description of OOXML, which accords with JTC 1 directives and which properly
services its design objectives and the likely needs of international users&quot;.
&nbsp;V1 should ask for no less. &nbsp; Remember, this 5-month review itself
is part of the &quot;process to in place to fix them [defects]&quot;, so
let's use it for that purpose.</font>
<br>
<br><font size=2 face="sans-serif">Regards,</font>
<br>
<br><font size=2 face="sans-serif">-Rob</font>
<br><font size=2 face="sans-serif">___________________________<br>
<br>
Rob Weir<br>
Software Architect<br>
Workplace, Portal and Collaboration Software<br>
IBM Software Group<br>
<br>
email: robert_weir@us.ibm.com<br>
phone: 1-978-399-7122<br>
blog: http://www.robweir.com/blog/</font>
<br>
<br><tt><font size=2>&quot;Rex Jaeschke&quot; &lt;rex@RexJaeschke.com&gt;
wrote on 05/12/2007 02:09:54 PM:<br>
<br>
&gt; Dear V1 Members,</font></tt>
<br><tt><font size=2>&gt; I&#8217;m writing the following in response to Patrick&#8217;s
recent posting <br>
&gt; about the process to be used to deal with the OpenXML DIS 29500 Fast<br>
&gt; Track. We&#8217;ll be discussing this topic on next Monday&#8217;s phone call.</font></tt>
<br><tt><font size=2>&gt; Introduction</font></tt>
<br><tt><font size=2>&gt; As many of us know from experience, making a
software specification <br>
&gt; of non-trivial size and complexity be perfect is extremely difficult<br>
&gt; and time consuming. And I think we all agree that DIS 29500 is of
<br>
&gt; non-trivial size and complexity. &nbsp;The pragmatic approach then
is to <br>
&gt; ask, &#8220;Is the DIS 29500 specification good enough for the current
and<br>
&gt; projected needs of business and industry? And if defects that <br>
&gt; materially affect those needs are found, is there a good enough <br>
&gt; process in place to fix them?&#8221;</font></tt>
<br><tt><font size=2>&gt; Hindsight is the most exacting science. Yes,
if we were starting <br>
&gt; from scratch, we'd all like to improve any standard on which we've
<br>
&gt; worked. However, in any standard that attempts to consolidate prior
<br>
&gt; art, as does DIS 29500, I hope we are beyond the point of trying to
<br>
&gt; make it perfect for perfections own sake.</font></tt>
<br><tt><font size=2>&gt; As such, with respect to DIS 29500, I see the
main task of V1 as <br>
&gt; reporting editorial and technical errors that impede or prohibit <br>
&gt; implementation of the specification. And since the submitter of such<br>
&gt; an error must explain the problem clearly enough for it to be <br>
&gt; addressed at any ballot resolution meeting, they are also in the <br>
&gt; best position to outline possible solutions. Indeed, I believe they
<br>
&gt; have an obligation to do so lest the error be considered purely academic.</font></tt>
<br><tt><font size=2>&gt; Document Review</font></tt>
<br><tt><font size=2>&gt; I see two approaches to performing a review of
the specification:</font></tt>
<br><tt><font size=2>&gt; &nbsp; 1. Let members &#8220;do their own thing&#8221;.</font></tt>
<br><tt><font size=2>&gt; &nbsp; 2. Break down the &nbsp;specification
into &#8220;bite-size&#8221; chunks and <br>
&gt; assign each to one or more members.</font></tt>
<br><tt><font size=2>&gt; The first option allows members to spend their
time on the topics <br>
&gt; that interest them, thereby allowing them to justify their <br>
&gt; investment. And while it might result in overlap among reviewers,
<br>
&gt; given the size of the specification, and the time available, that
is<br>
&gt; unlikely. In any event, as editor, I view multiple independent <br>
&gt; reviews of Part 1 and the intro material for each ML in part 4 to
be<br>
&gt; most welcome.</font></tt>
<br><tt><font size=2>&gt; &nbsp;</font></tt>
<br><tt><font size=2>&gt; The second option might provide good and thorough
coverage, but <br>
&gt; requires serious organization and time. It also requires members to
<br>
&gt; agree to work on subject matter that might not interest them or be
<br>
&gt; relevant to their reasons for participating in V1. In any event, <br>
&gt; there are obvious ways in which to break down the specification.</font></tt>
<br><tt><font size=2>&gt; I favor the first option.</font></tt>
<br><tt><font size=2>&gt; Recording of Issues</font></tt>
<br><tt><font size=2>&gt; I&#8217;ve managed four lots of comment submissions
for Fast-Track <br>
&gt; projects, and the best approach I&#8217;ve found is described below.</font></tt>
<br><tt><font size=2>&gt; Ultimately, we&#8217;ll have to submit any comments
using the JTC 1-<br>
&gt; sanctioned comment form (see attached). As such, I believe that we
<br>
&gt; should use that form throughout our entire issue-gathering process.
<br>
&gt; Specifically, anyone who submits a comment (and, hopefully, a <br>
&gt; proposed resolution) does so using this form. Then issues get added
<br>
&gt; to the master list (maintained by Patrick, perhaps?), which also <br>
&gt; uses that form. Patrick can assign each issue on the master list a
<br>
&gt; sequential issue number. Periodically, he&#8217;d circulate the current
<br>
&gt; master issues list, so we&#8217;re all in sync.</font></tt>
<br><tt><font size=2>&gt; &nbsp;</font></tt>
<br><tt><font size=2>&gt; We can use (the otherwise unused) column 7 to
keep an audit trail of<br>
&gt; the issue: Add a date stamp for when the issue was raised, then each<br>
&gt; time the issue has had non-trivial decisions, along with details of
<br>
&gt; the discussion. We can color cells (or whole rows) in the table to
<br>
&gt; highlight issues and attributes, such as &#8220;pending&#8221;, &#8220;closed&#8221;,
and <br>
&gt; &#8220;rejected&#8221;. We can even add new rows/columns to the table for our
<br>
&gt; own internal purposes.</font></tt>
<br><tt><font size=2>&gt; &nbsp;</font></tt>
<br><tt><font size=2>&gt; At the end of our deliberations, we simply clear
column 7, delete <br>
&gt; any housekeeping rows/columns we&#8217;ve added, delete those rows <br>
&gt; pertaining to issues that are not to be forwarded, and remove any
<br>
&gt; other extraneous notation we may have added.</font></tt>
<br><tt><font size=2>&gt; The primary advantage of this approach is that
we always see each <br>
&gt; issue presented in the manner in which we have to submit it. My <br>
&gt; experience has shown that if we don&#8217;t use this kind of approach,
we&#8217;<br>
&gt; ll submit comments to V1 in different forms using different tools,
<br>
&gt; and, at the last minute, when the final set is moved to the required<br>
&gt; format, we&#8217;ll have had little or no experience at looking at them
in<br>
&gt; that form, so won&#8217;t be as confident of the fidelity of the <br>
&gt; translation that went on.</font></tt>
<br><tt><font size=2>&gt; Public Access to Committee Work</font></tt>
<br><tt><font size=2>&gt; Patrick asked, &#8220;&#8230; whether we want to have a
wiki for which there is <br>
&gt; read access by the general public but write access only by V1 <br>
&gt; members, for the discussion of issues?&#8221;</font></tt>
<br><tt><font size=2>&gt; An INCITS TC&#8217;s primary obligation is to follow
the wishes of its <br>
&gt; voting membership within the rules. Membership of a TC is open to
<br>
&gt; anyone who can afford the fee and the time to participate, which <br>
&gt; allows any interested/affected party to participate. That&#8217;s the <br>
&gt; value-added proposition of being a member; you get to sit at the table!<br>
&gt; A TC has no obligation to the general public at large although one
<br>
&gt; can construct rationale for keeping them &#8220;informed&#8221;. (The INCITS,
<br>
&gt; JTC 1, and Ecma committees on which I have been participating do <br>
&gt; that via periodic news releases or summary documents on the public
<br>
&gt; part of their websites. None of them makes documents on &#8220;in-<br>
&gt; progress&#8221; topics available outside the committee.)</font></tt>
<br><tt><font size=2>&gt; What does V1 do in this regard for its other
projects? Are we being <br>
&gt; consistent?</font></tt>
<br><tt><font size=2>&gt; With respect to making issues public once V1
has formed an official <br>
&gt; position on them, I believe that nothing is official until the final<br>
&gt; vote is taken. Each voting member reserves the right to change their<br>
&gt; mind until the end (note the non-trivial percentage of undecideds
in<br>
&gt; polls leading up to elections here in the U.S.). Publishing a 5/4
<br>
&gt; vote on an issue one week and then publishing a revised vote of 4/5
<br>
&gt; on that same issue two weeks later, doesn&#8217;t help the public, and
<br>
&gt; probably confuses them, yet still gives rise to media/bloggers&#8217; <br>
&gt; distorting the real situation.</font></tt>
<br><tt><font size=2>&gt; Summary</font></tt>
<br><tt><font size=2>&gt; Here then are my recommendations:</font></tt>
<br><tt><font size=2>&gt; 1. Members review whichever parts and clauses
of the specification <br>
&gt; they see fit.</font></tt>
<br><tt><font size=2>&gt; 2. Members only report editorial and technical
errors that impede or<br>
&gt; prohibit implementation of the specification.</font></tt>
<br><tt><font size=2>&gt; 3. Any member submitting an error must explain
the problem clearly <br>
&gt; enough for it to be addressed at any ballot resolution meeting, and
<br>
&gt; should do their best at outlining possible solutions.</font></tt>
<br><tt><font size=2>&gt; 4. All comments should be submitted to V1 using
the JTC 1 comment form.</font></tt>
<br><tt><font size=2>&gt; 5. Information shared with the public at large
be restricted to <br>
&gt; generic status reports, and not cover specific issues or positions.</font></tt>
<br><tt><font size=2>&gt; Rex</font></tt>
<br><tt><font size=2>&gt; ----------------</font></tt>
<br><tt><font size=2>&gt; Rex Jaeschke &nbsp; http://www.RexJaeschke.com
&nbsp; Skype: RexJaeschke</font></tt>
<br><tt><font size=2>&gt; 2051 Swans Neck Way, Reston, VA, 20191-4023,
USA</font></tt>
<br><tt><font size=2>&gt; Phone: +1 703 860-0091, Fax: +1 703 860-3008</font></tt>
<br><tt><font size=2>&gt; &lt;&lt;...&gt;&gt; [attachment &quot;ISO Comment
Template.doc&quot; deleted by Robert <br>
&gt; Weir/Cambridge/IBM] </font></tt>

--Boundary_(ID_VMFxj6P3PQhqUnN5UdfKTw)--

