WG or IG?

As we discussed at Boston, it should be the discretion of the IG co-chairs 
to copy comments and technical dialog to the IG list, when originally sent 
to the WG list.

I couldn't decide about this one.  On the one hand, it might draw some 
interesting discussion.  On the other, it is a specific email contribution 
towards resolution of the issue (for discussion and approval/rejection Mon 
or Thurs).

Lynne, Olivier -- you decide!

-Lofton.

>Resent-Date: Fri, 4 Apr 2003 13:35:41 -0500 (EST)
>X-Sender: lofton@rockynet.com
>X-Mailer: QUALCOMM Windows Eudora Version 5.1
>Date: Fri, 04 Apr 2003 11:37:09 -0700
>To: www-qa-wg@w3.org
>From: Lofton Henderson <lofton@rockynet.com>
>Subject: LC-100 -- discouraging extensibility
>X-Archived-At: 
>http://www.w3.org/mid/5.1.0.14.2.20030404110502.04220330@rockynet.com
>Resent-From: www-qa-wg@w3.org
>X-Mailing-List: <www-qa-wg@w3.org> archive/latest/1756
>X-Loop: www-qa-wg@w3.org
>Sender: www-qa-wg-request@w3.org
>Resent-Sender: www-qa-wg-request@w3.org
>List-Id: <www-qa-wg.w3.org>
>List-Help: <http://www.w3.org/Mail/>
>List-Unsubscribe: <mailto:www-qa-wg-request@w3.org?subject=unsubscribe>
>X-RCPT-TO: <lofton@rockynet.com>
>
>
>Ref:  http://www.w3.org/QA/WG/lc-issues#x100
>
>Submitter states:  "The position of the QA framework WG, that extensions 
>should not be allowed, is quite clear. This is a political position, and 
>doesn't accomodate those working on specifications that clearly demand 
>public extensibility"
>
>There are two errors in this statement:
>
>1.) "[QAWG position is...] extensions should not be allowed".  This is 
>inaccurate.  The specification [1] says: "Exercise caution in determining 
>the extent to which extensions are allowed or not allowed. Since 
>extensions can seriously compromise interoperability, specification 
>writers should carefully consider whether extensions should be allowed."
>
>It does NOT say that extensions should not be allowed, but it advises 
>specification writers to carefully consider the often-negative impacts and 
>implications, and make and document their decisions accordingly.
>
>(The title of the issue "...discourage..." is more accurate than its 
>statement -- we do discourage it unless it is well justified.)
>
>2.) "This is a political position, and doesn't accomodate those working on 
>specifications that clearly demand public extensibility"  This is also 
>incorrect.  The entire extensibility content of SpecGL is based 
>significant experience with standards and extensibility, including 
>experience where unfettered extensibility has basically ruined the uptake 
>of an otherwise good standard in the field.  It is NOT political, it is 
>based on fact and experience.
>
>Despite our bias against extensibility -- because it has often been used 
>carelessly with disastrous interoperability impacts, or as an easy way to 
>avoid hard decisions in writing the standard -- we nevertheless recognize 
>that a total ban is inappropriate.  And that is reflected in the language.
>
>IMO, Guideline 9 and its checkpoints strikes a decent balance, and I think 
>what it clearly states is contrary to the premises of this comment.
>There are some other specific extensibility issues which might lead to 
>some fine tuning within the checkpoints.
>
>Proposed resolution.  The comment misconstrues the actual specified 
>intents of GL9 and its checkpoints, which intents are clearly spelled out 
>in the 2nd and 5th paragraphs.  Point this out to originator, no change to 
>document.
>
>(Note.  This does not mean that I think some of the language in the 
>checkpoints cannot be fine tuned and improved -- I think that it can, per 
>some of the other specific extensibility issues.)
>
>Regards,
>-Lofton.
>
>[1] http://www.w3.org/TR/2003/WD-qaframe-spec-20030210/#Gd-extensions
>

Received on Friday, 4 April 2003 13:40:25 UTC