Thursday Morning Minutes of Reading F2F

QA Working Group F2F
Thursday, 28-October-2004
--
Scribe: Mark Skall 

Attendees:
(PC) Patrick Curran (Sun Microsystems)
(DD) Dimitris Dimitriadis (Ontologicon)
(KD) Karl Dubost (W3C, WG chair)
(DH) Dominique Hazaël-Massieux (W3C)
(LR) Lynne Rosenthal (NIST - IG co-chair)
(MS) Mark Skall (NIST)
(AT) Andrew Thackrah (Open Group)

Regrets: 

(RK) Richard Kennedy (Boeing) 
(LH) Lofton Henderson (CGMO)


Absent: 


Summary of New Action Items: 
AI-20041028-1 LR and MS to re-write technique for determining a conformance 
model to reflect “what does it mean” by Nov. 5, 2004.
AI-20041028-2 KD to create Wiki topic to address the issues involved in 
normative references by Nov. 4, 2004.
AI-20041028-3 KD to write principle and good practice on normative references, 
including time considerations, super setting or sub setting, and breaking 
conformance by Nov. 4, 2004.
AI-20041028-4 PC will re-write section on mandatory modules by 12 noon, today, 
Oct. 28, 2004.



Agenda: http://www.w3.org/QA/2004/10/f2f


Minutes: 

The WG will be going through the outstanding issues with respect to SpecGL.

KD – Issue 001 (from LR) is to make sure that people know that principles are 
normative and rest is informative.  “Must” used in a lower case form

DH – Must specify that conformance clause is normative as well.

KD – Must add something on the prose to make things normative.

DH – Shouldn’t glossary be normative?

MS – Glossaries are not normally normative.

PC – I agree. Let’s not make glossaries normative.

DH – Do not need to label sections as normative or not. Makes it non-readable.

LR – We have a good practice to do this.

LR - According to the definition of normative, the glossary cannot be.  Remove 
QA glossary from the list of references.  Good practices allow a table instead 
of labeling each section.

Issue 002:  Technique on determining a conformance model is too 
profile/module/level focused.  Perhaps we should re-write techniques to 
reflect “what does it mean”? AI – LR and MS will work on it by Nov. 5.

Issue 003 - When making a normative reference, you need to see how future  
versions of the said specification may affect your own document. But  
how do you evaluate that. How are you sure that you will be able to  
make reference to something you do not necessary control.

PC – Can we bind ourselves today to a future version of a spec? No.

DH – How can references be used as an extension mechanism.

PC – Can you modify conformance requirements of reference specification for 
use with a given spec?  You should be able to make them stricter for your use, 
but you shouldn’t use a subset.

DH – You may need subsets so how do we incorporate them?

PC – If you’re sub setting spec or super setting it, say so and use a 
reasonable boundary.

MS – Shouldn’t we conform to outside spec and only use subsets if the spec 
allows subsets?

KD - We need principles and best practices with respect to how to make 
normative references, especially to future specifications.

KD – What are good practices and principles?

PC – If you are modifying reference specs, make explicit the relation between 
your techniques and your normative references (i.e, list references, explain 
which parts of references you are using, warn the implementer if you are sub 
setting or super setting the referenced spec.)

KD – Principle should be “List all your normative references”; Good Practice – 
Don’t redefine conformance model for your use.”

DH – Don’t agree.  Let’s just say what they do, not whether they should do it.

Consensus – Make explicit the relationship to your references.

KD – AI to create Wiki topic to address the issues involved in normative 
references by Nov. 4.
KD – AI to write principle and good practice on normative references, 
including time considerations, super setting or sub setting, breaking 
conformance by Nov. 4.

KD – Issue 004 pertains to 3.1 Good Practice C – need new wording.  What 
does “terms” refer to?  

PC – Put in “unfamiliar terms”.

KD – Issue 005 - 4.1 Good Practice A – “Use cases” was too specific.

LR, MS – Take out “by the variety of use cases.”

KD – Issue 006 - MS’s review of 2.1 Good Practice C.  Richard Kennedy has also 
reviewed that.  KD will merge the 2 re-writes together.

KD – Issue 007 from LR – “Reference to TestGL to be removed.”  Agreed.

KD – Issue 008 – Examples given by Jeremy Carroll for DOV – We don’t use them –
 should we?  We will use his examples/story.

KD – Issue 10 – Lofton - 1.1 Good Practice C.  Specify in the conformance 
clause how  
to distinguish normative from informative content  – defer to the afternoon

KD – Issue 011 – DM - not strong enough about mandatory modules.  Should 
modify techniques and models.  PC will re-write this section by 12 noon.

KD  - Issue 012 – DM wants to modify graph under 4.1 Good Practice A.  We may 
want to apply the change to Variability in Specifications, not to SpecGL.

LR – Numbering scheme in SpecGL.  Is scheme overly complex?  

DM – Suggestion to rename/renumber sections in the following way: 3.1 A 
Principal rather than 3.1 Principal A.

MS – We should mmake sure that the principles precisely define requirements 
and are testable.

Principles were reviewed and (depending on who), either 2 or 3 were found to 
be non-testable.

The WG rewrote 3.2 Principle A to consist of: Principle – Explain how to 
identify conformance requirements.  Good practice – keep consistent style.

Meeting adjourned for lunch at 1230.

Received on Thursday, 28 October 2004 12:42:53 UTC