Draft Minutes for March 3 PM F2F

QA Working Group Face-to-Face, Boston
Thursday PM, 3-March-2005
--
Scribe: Mark Skall

Attendees:
(PC) Patrick Curran (Sun Microsystems)
(KD) Karl Dubost (W3C, WG co-chair)
(DH) Dominique Hazaël-Massieux (W3C)
(LH) Lofton Henderson (CGMO - WG co-chair)
(LR) Lynne Rosenthal (NIST - IG co-chair)
(MS) Mark Skall (NIST)
(RK) Richard Kennedy (Boeing)
(TB) Tim Boland (NIST)


Regrets:
(DD) Dimitris Dimitriadis (Ontologicon)

Absent:

Guest:

(DM) David Marston (IBM)

Summary of New Action Items:

AI-20050303-1   LR to provide a 1 sentence disclaimer in the”What does it 
mean” section that the ICS should positively emphasize that it’s not about 
conformance.
AI-20050303-2   KD to update SpecGL to incorporate issue 1042 into SpecGL, 
concluding that the Scope helps determine whether the spec is overstepping 
its mandate.
AI-20050303-3   KD to draft response to Issue 1045:  Avoiding 
device-dependent profiles.
AI-20050303-4   DH to draft response to the XML Core WG to respond to issue 
1052.

Agenda: http://www.w3.org/QA/2005/03/f2f
Previous Telcon Minutes:


Minutes:

The afternoon session was spent going over unresolved SpecL issues.

Issue 1041 – Conformance is not a yes/no proposition
(LH) Ian’s comment is confusing an ICS with a conformance claim.  Yes/no or 
not applicable is only marginally useful since it is only a box that is 
checked.  Ian thinks you should link to a test suite that shows your 
results with respect to the tests.
(MS) This may be done before it is appropriate to run with a test 
suite.  The intent is to have implementer tell buyers and others what 
he/she intends to support.
(LH) Techniques should include more things than it currently does.   Should 
allow for self declaration.
(TB) This is not intended to determine conformance.  It is only one part of 
a conformance claim.
(DM) There might be 2 phases.  We need to record intent.  Yes or no 
suffices for the intent phase.  Phase 2 is the conformance claim.
(DH) ICS can be used in many ways.  It can have many purpose, can be part 
of a conformance claim.
(MS) Intent is important and intent is to give preliminary indication to 
buyers and to testers.  Conformance claim is different and should depend on 
passing the  tests.
(LH) It can be used in 2 ways.  It should be clear what “yes”, “no” 
means.  Different specs may have different needs.  Used in different ways 
and we should make it clear in this section.
(MS) Again, it will complicate the ICS and make it hard to understand.
(LR) Problem with allowing ICS to mean multiple things is the confusion of 
which thing an implementation is talking about.
(RK) Why should an ICS appear in a spec guideline?
(DH) We’re just asking an ICS to appear.
(DH) If we can document intent, that’s okay.
(MS) Other intent of ICS is the same as a “conformance claim”.  That is 
confusing.
(KD) Can be used for 3 different things.
(DH) If it may be used for 3 different things, this would be more confusing.
(LH) A large spec doesn’t necessarily lead to a huge ICS.
(DH) Should limit ICS to just declarative, but an ICS linked to tests that 
are passed can strengthen a conformance claim.
(LH) Should take conformance out if we say that.  ICS should not imply 
anything about conformance and positively emphasize that it’s not about 
conformance.  Action item for Lynne to provide a 1 sentence disclaimer in 
the ”What does it mean” section.
(LR) I took it out and re-wrote it to explain this.
Consensus:  Should limit ICS to just declarative, but an ICS linked to 
tests that are passed can strengthen a conformance claim.

Issue 955
(LH) TAG requested that there should be positive statements about features 
(e.g., state that there are no deprecated features.)
(TB) It may be difficult to determine the presence of a deprecated feature 
since things may be combined.
(DM) Can usually get answers about deprecated features from test suite.
(DH) We agree there should be a positive statement about features.  If they 
don’t exist, it should be stated.
(LR) Are we listing all optional features?
(DH) Only if optional features exist.
(LH) Should enumerate optional features, if small enough in the conformance 
clause.
Consensus: We agree there should be a positive statement about features 
referred to in every Good Practice.  If they don’t exist, it should be 
stated in the conformance clause.

Issue 983 – Example for an ICS claim
(DH) Wording is confusing.  There are pending action items to resolve issue.
Issue 990.  Prevent extensions from breaking conformance.
(DH) Decided during last telcon to close issue.

Issue 1042
Scope helps determine whether spec is overstepping its mandate.
(DH) Editorial as long as we agree with comment.
(KD) Action item to update SpecGL to incorporate about issue.

Issue 1044  Case of RFC2119 terms
(KD) Old action item to write something about this.

Issue 1045 Avoiding device-dependent profiles
(DH) We are discouraging this and point to where this can hurt 
interoperability.
(KD) Action item to draft response.

Next face to face meeting – Targeting Dublin with back-ups of Montreal and 
Sophia, France – June 21-23.

Issue 1050 – Modesty Requirement
This issue says we should discourage specs from making claims they are QA 
conformant to QA,etc.
(DM) We encourage conformance claims to QA because there are objective 
criteria.  If there are no objective criteria, claims shouldn't be 
made.  There will be no change to SpecGL. This was the consensus as well.

Issue 1051 "Identify deprecated features" too strong
This issue says this is too strong because it only applies to a second 
version of a specification.  Will incorporate this into SpecGL.

Issue 1052 "Classes of product" unclear and dangerous
(DH) Redefine “classes of products” to make it less open ended and restrict it.
(DM) Can say “this is the set that should be checked by the test suuite”.
(DH) Do we want to be exhaustive?
(DM) Only to what is supported currently.
Consensus: There will be a link from Section 2.2 A to the Variability in 
Specification document (CoP section).  There will also be a link to the 
defintion.
Consensus: Change “To which the specification applies” to “which 
requirements are imposed upon” the CoP in the "what does it mean?” section.
AI – Dom to draft response to the XML Core WG.

Issue 1058 – Structure and numbering confusing.   Only some parts of the 
document are numbered and numbering scheme not consistent.
(TB) Need to better explain scheme and make sure Good Practices are linked 
form Table of Contents.

Issue 1061 – argues that if there are no requirements it is not a 
specification.
Consensus – We will change “specification” to “technical report” in the 
“About This Document” Section.
Consensus – There should still be a conformance clause even for 
specifications that are not normative.
Adjourn at 1700.

Received on Friday, 4 March 2005 14:25:54 UTC