Fwd: Ungrouped issues -- a plan for Monday


Our first topic on Monday's Telecon (July 7) will be to conclude the 
discussion regarding MUST use MUST.  Followed by leftover LC SpecGL 
comments.  Many thanks to Lofton for preparing this.

>LC-17:  LC-17 (can deprecated features be "distributed" throughout spec?)
>Proposal (DM).  No!  (There must be a single point of entry, Conformance 
>Clause, to find all deprecated features.  Presumably, it could be a list 
>of links that simply points to the location(s) in the text?)
>LC-20 [editorial] (single section okay for "universal rqts"?)
>Proposal (LH).  Single.  As we have clarified CCP3.1, its whole nature is 
>defined somewhat differently.  It is a summation of information that could 
>be deduced from other individual requirements.  Therefore only "single" 
>makes sense.
>LC-29.1 (how should "performance requirement" be handled)
>Proposal (LH).  If "performance requirement" is written like any other 
>"conformance requirement", then what is the issue?  Do we say anything in 
>SpecGL that implies that a PR cannot be a CR?
>LC-29.2 (configurability versus functionality considerations)
>How does this comment affect SpecGL?
>LC-29.3 (inclusion of one spec's requirements into another spec)
>Is this within the scope of SpecGL?
>LC-34 [editorial] (eliminate unnecessary sentence)
>[See new "Proposal".  Okay?]
>LC-64 [editorial] (conf. terms must be defined?)
>[Accept originator proposal?]
>LC-73.7 ("Normative refs" requirement should be P1)
>[Accept originator proposal?]
>LC-77.SG-2 (Use standard headings)
>[It sounds good in theory.  Intro, Concepts, Guidelines, Conformance, 
>...  But for example OpsGL doesn't have a Concepts chapter (should 
>it?).  And ... to what level of sub-section, sub-sub-section, etc, should 
>we try to remain standard?]
>LC-78 (provide conf-disclaimer template)
>[Good idea.  QAWG volunteer to write it?  (editors?)]
>Leave it to editors:
>LC-19 (clarify "[profiles] experience has shown)
>[See new "Proposal".  Okay?]
>LC-22 [editorial] (CP 2.3 placement of Checkpoint)
>[Let the editors make it consistent.]
>LC-25 [editorial] (scope/goals suggestion)
>[Proposal.  It seems to fit better in "C.o.P and Audience", or 
>"Understanding and using this document".  If reworded, it could look more 
>"scope-ish" -- i.e., scope is specifically "new TRs" -- but I think 1.2 or 
>elsewhere might be better.]
>LC-28 (use stylesheets to hide links in printed versions of SpecGL)
>[Do the editors agree?  Maybe Karl can do a little more CSS magic.]
>LC-29.6 (indicate normativity of examples & illustrations)
>[Just looks like a small edit on the "Distinguish normative and 
>informative text." stuff.  Maybe replace "text" with "content", and then 
>elaborate content in ConfReq or Discussion or ...]
>LC-73.8 (Add Rationale and Discussion to CP13.3)
>[Editors discretion, do it if it seems to help or clarify.]
>LC-77.ET-1 (Explain SpecGL/ET pairing better.)
>[Reasonable.  See
>http://www.w3.org/QA/WG/2003/06/qaframe-ops-20030623#relationship-to-spec ,
>is this good enough?]
>LC-77.ET-4 (When will SpecET be released.)
>[There will be a new SpecET with next published SpecGL.]
>LC-88 [editorial] (reformat bullet list)
>[Seems reasonable.  Leave decision and response to the editors.]
>### end ###
>[1] http://lists.w3.org/Archives/Public/www-qa-wg/2003Jul/0007.html

Received on Sunday, 6 July 2003 18:37:08 UTC