Fwd: Making SpecGL 7.3 more obvious

Telecon participants --

Today we hope to get into the DoV issue set.  The first one is #21 [1].  It 
is similar to the #99 for which David had a drafting assignment (below 
attached).

Proposal:
-----
It occurs to me that we might, in our DoV discussion (sub-) section, try to 
genericize an explanation of this concept which is repeated in each 
CP.  Then each of these CP could back-link to that conceptual discussion, 
and add any further specialization for the particular topic, some "for 
examples", etc.

-Lofton.

[1] http://www.w3.org/QA/WG/lc-issues#x21


>Resent-Date: Thu, 17 Apr 2003 16:47:18 -0400 (EDT)
>Sensitivity:
>To: www-qa-wg@w3.org
>X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
>From: david_marston@us.ibm.com
>Date: Thu, 17 Apr 2003 16:46:35 -0400
>X-MIMETrack: Serialize by Router on CAMMAIL08/CAM/M/Lotus(Release 
>6.0|September 26, 2002) at
>  04/17/2003 04:46:36 PM
>Subject: Making SpecGL 7.3 more obvious
>X-Archived-At: 
>http://www.w3.org/mid/OF5A782799.08E814D6-ON85256D0B.006E630E@lotus.com
>Resent-From: www-qa-wg@w3.org
>X-Mailing-List: <www-qa-wg@w3.org> archive/latest/1851
>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>
>
>
>
>
>
>
>I have an action item to redraft Ck 7.3 to address issue LC-99. Here
>is the attempt.
>
>==================================================================
>Checkpoint 7.3 If deprecation is used, define its relationships and
>interaction with other dimensions of variability. [Priority 2]
>
>Conformance requirements: the specification must indicate, for each
>deprecated feature, either that it is independent of all other DoV or
>else discuss the relationship between the feature and all other DoV.
>
>Rationale: A deprecated feature could be a feature that was originally
>present only in a particular class of product, module, level, etc. or
>it could be a feature that was originally required of all
>implementations. But an entire module, level, etc. could be deprecated.
>Additionally, new discretionary choices could be spawned because a
>feature has been deprecated. (Example: an implementation must either
>accept content with the deprecated feature and process it as in the old
>version, or offer a strict/lax option to control acceptance or
>rejection end of such content.) As a further example, observe that the
>MathML 1.x deprecated features discussed under Checkpoint 7.2 above
>vary with respect to the class of product, because the deprecation
>policy for producer products differs from the deprecation policy for
>consumer products.
>==================================================================
>
>Additional comment about that last bit: Discussion of the interaction
>between class of product (GL 2) and deprecated features (GL 7) is P1;
>discussion of the interaction between deprecated features and *all*
>DoV is P2. I don't have a problem with that.
>
>General comment: when assessing the spec on interaction-among-DoV
>checkpoints, or when writing a conformant spec, one should probably
>take each instance of a DoV feature and ask how it is affected by any
>of the other DoV that are used. That's part of how I arrived at the
>ordering of the DoV. In the current case, I am saying that you assess
>conformance to Ck 7.3 by taking each deprecated feature (not just the
>presence of deprecated features in general) and asking:
>Does this feature vary by class of product?
>Does this feature's deprecation status interact with strict/lax policy,
>    minimum requirements, backward-compatibility policy, etc. (GL 3)?
>Does this feature vary by profile? Or, are some profiles deprecated?
>Does this feature vary by module? Or, are some modules deprecated?
>Does this feature vary by level? Or, are some levels deprecated?
>Does this feature, by virtue of being deprecated, cause discretionary
>    items to apply in a varying way? Could a discretionary item affect
>    the feature's deprecation policy? Are new discretionaries spawned?
>Does this feature affect extensions or an extensibility mechanism?
>
>As always, deprecation presents an interesting wrinkle to the general
>policy that versions are not a DoV. You can't have deprecation without
>having more than one version, at least the way the W3C does things.
>More broadly, you can't have a backward-compatibility policy (of which
>the deprecation policy is a part) without having more than one version.
>Nonetheless, the backward-compatibility policy only applies to the one
>version being specified.
>.................David Marston

Received on Friday, 18 April 2003 10:45:23 UTC