Proposed text for SpecGL LC comments

QA WG

A current working version of SpecGL is available at: 
http://www.w3.org/QA/WG/2003/07/qaframe-spec.html
We are still working on the document, but as you can see much has been done 
and is still being done.  Things that still need to be done include:
1. GL8 - to review what DM drafted, modify his 8.4 and maybe other parts 
and put it into the document
2. GL9 - there were several comments and changes to make.  I am also 
supposed to add a new CP
3. Reorder and Merge:  GL 13, 10/3, 11/12  and make appropriate 
modification to text
4.  Modify section 3.2 Extensions - in crete we said that A+ (doing A and 
some AA and some AAA) was not an extension.

Below are many of the LC issue resolutions and the text that has been 
incorporated.  Any comments?
--Lynne

++++++++++++++++++++++++++++++++++++

LC93, 94, 48, 46 (to make it clearer what we are referring to and that the 
list is non-exhaustive
-- CP2.2  Added an explanation
The list of classes of products (Table 2) enumerate the most common classes 
of products.  If your class of product matches one or more terms in the 
list, then use the terms in the list. If no term is an appropriate match, 
then define your own.
-- CP2.3  Added an explanation and clarification in the rationale
Understanding the kind of specification that is being written, contributes 
towards understanding the target of the specification, i.e., the applicable 
classes of products.
  Moreover, it helps both the author(s) and readers understand the scope of 
the specification and its focus.   The list of specification categories 
(Table 1) enumerate the most common categories of specifications.  If your 
specification matches one or more a categories in the list, then use those 
categories.  If no category is an appropriate match, then define your own.

LC 23, 75.1, 92, 79   Examples, use cases etc.
Clarified 1.2 and 1.4, moved 1.3 to follow 1.4
Modifications to CP1.2
- changed title: Illustrate scope
- modified rationale, now reads:  a set of broad examples and/or use cases 
helps to clarify the specification's scope. It gives the reader additional 
information in understanding the purpose, audience, and applicability of 
the specification. These examples and use cases may be included in the 
specification or may be in a separate document referenced by the 
specification.  It is up to the Working Group to determine what the best 
way to illustrate the scope, i.e., to use examples or use cases or both.

Modifications to CP 1.4 (now becomes new CP1.3)
- changed title: Illustrate functional details
- modified rationale, now reads:  it is difficult to understand some 
concepts, behavior, or functionality without informative interpretations to 
aid the reader. These examples are specific in nature and are use to make 
clear a concept, behavior, interaction, etc. that is innately complex or 
for which the WG has had to explain to its members or the public.

LC issues regarding CP1,2, 1.3, 1.4  closed
--LC 109  merge CP1.3 with CP1.2
Done.  Added 'Use cases are a valuable way to describe the different ways a 
specification can be used' to explanation of CP1.2
--LC LC 23  be more specific for 'provide examples'
Added:  The nature of the specification will influence the type of examples 
that are relevant.  For example, for markup specifications, provide at 
least one example of each markup construct; for transformation 
specifications, illustrate each transformation capability with an example 
showing input and output.
--LC 75.1  reorder CP according to Priority
Moot.  CP1.3 deleted.
--Note: 79 and 92 already closed.  77.ET-2 needs to be implemented in ET

This completes LC 96 and 42: GL3-policy
--LC96:  clarified universal requirements
New Rationale: the reader must be able to recognize any minimum functionality,
complexity, or support that applies to conforming products of a specific
class. These minimum requirements can be considered a starting point for a
checklist to be used by a team developing a conforming product.  It helps
the reader find these requirements by presenting them as a collection, in
one place rather than distributed throughout the document.  This collection
may be derived from the distributed requirements and may apply to a single
class of product or across classes of products.

--LC 42 (already done --  Removed 'possibly') Note, when GL3 is combined 
with GL10, some of this may go away.

FROM LH's Ungrouped issues email, 6 July
LC17: can deprecated feature be distributed
Added Rationale: It helps the reader find these requirements by presenting 
them as a collection, in one place rather than distributed throughout the 
document. This collection may be derived from the distributed requirements 
and may apply to a single class of product or across classes of products.

LC20  single section for universal rqts?
Moot.  Clarified CP3.1 as a collection.

LC29.1,
If performance requirements are part (i.e., requirements) of a 
specification, then they are like all other conformance 
requirements.  Else, they are outside the scope of conformance.

LC-29.2
The desirability of some requirements vs other requirements can be 
considered and handled as DoV. The SpecGL doesn't specifically address the 
idea that some requirements are more important than other.  Although no 
specific guidance is given, it isn't precluded either.  This may be an area 
to address in a future version of SpecGL.

LC - 29.3
Interesting points, but outside scope.

LC34 Section 3.4 conformance definition.
Modified as per proposal  replaced 'individual' with 'mandatory'. Deleted 
second sentence.

LC64  CP 3.2 conf terms defined
Done previously, modified/clarified ConReq: 'any conformance concepts used 
in the specification MUST be defined, either by reference or by including 
the definition in the text.'

LC73.7 change Priority of CP10.2
Accepted  changed to P1

LC77.SG-2 (Use standard headings)
Agree that this is a good guide and we will adhere to it, as best we can, 
recognizing that each Framework document may have unique chapters.  All 
documents will have the same core headings and in the same order:  Intro, 
Guidelines, Conformance, Definitions (if applicable), Acknowledgements, 
References, Change History.
No changes to SpecGL needed.

LC78 template for conformance claims
Agreed, good idea.  Will be implemented as resources are available.
No changes to SpecGL needed.

  LC19  clarify [profile] experience
Added to explanation:  Previous experience in W3C (e.g., creation of 
WebCGM) and by other organizations in creating derived profiles or defining 
rules for profiles

LC22 placement of CP2.3 with respect to introduction's categorization of 2 
types of guidelines
Yes, a part of CP2.3 deals with where the information needs to be 
placed.  Due to many changes, this intro text may need to be rewritten  For 
now, I've deleted the mention of which Guidelines fall into which general 
type.  It may be that a guideline falls into both categories.
(temporarily closed, but should revisit)

LC25 scope/goals of Sec1.1
Deleted from Sec 1.2  (this was done prior to today, july 16).  I think 
that it is no longer needed since we have the use cases, which cover the 
intent of this text.

LC28 use stylesheets to hide links
???. I think the idea is to have a collapsible ToC, which expands when you 
link to a section and that there be a option for a printable version of the 
document, etc.
Nothing to edit in SpecGL

LC29.6 indicate normatively of examples and illustrations.
Yes, will do this.  Currently, there are no normative illustrations or 
examples.  Do we need to explicitly label examples/illustrations as 
informative  I don't think we do.

LC88 Reformat bullet list.
Comment references CP1.3, which doesn't have a bullet list.  I think this 
refers to the 8 items in the DoV.
No objection from me to use something other than bullets.

LC73.8- add rationale to CP13.3
Rationale: Being consistent and following established conventions and W3C 
editorial practices will enhance the readability and comprehensibility of 
the specification.

LC-8 Checkpoint 1.1 is wooly
Reworded Title: Include a scope statement.
Reworded the explanation. The scope describes the areas covered by the 
specification, thereby indicating the intent or applicability of the 
specification. It does not specify requirements and is worded as a series 
of statements of fact.

LC61 done (as result of other LC issues)
new class called 'specification' added

Added definition for 'derived profile', since no one (answered my email 
and) sent one.
derived profile
a profile that is created from a set of profile rules, where these profile 
rules provide instructions for buiding (i.e., defining profiles) and the 
rules are defined in a specification.

LC14 clarify CP14.1 separate document for TA
Clarified and Modified GL and CP explanations-In GL explanation, modified 2 
sentence: It is derived from the specification's requirements and provides 
a normative foundation from which test cases can be built.
--In GL explanation added at the end:  It is recommended that test 
assertions be available by the time a specification enters Proposed 
Recommendation.
--In CP14.1 modified explanation: In order to enable traceability from the 
tests back to the test assertions, use a mechanism for making explicit test 
assertions in the specification. The list of test assertions can be 
included in the specification or in a separate document that is referenced 
by the specification. Test assertions may be developed by the specification 
authors, others members of the WG or people external to the WG.


LC29.4 characteristics of technical requirements
The suggestion of desirable characteristics, e.g., independence, minimal, 
distinguish and label  are exactly what we define/describe for TAs.  Do we 
need to do anything to close this LC  other than acknowledge the comment 
and say that we advocate this for TAs, which are the specific requirements 
from which tests would be built?