QA WG 20050131 telcon minutes

QA Working Group Teleconference
Monday, 31-January-2005
--
Scribe: Dimitris Dimitriadis

Attendees:
(TB) Tim Boland (NIST)
(PC) Patrick Curran (Sun Microsystems)
(DD) Dimitris Dimitriadis (Ontologicon)
(KD) Karl Dubost (W3C, Chair)
(DH) Dominique Hazael-Massieux (W3C)
(RK) Richard Kennedy (Boeing)
(LR) Lynne Rosenthal (NIST)
(DM) Dave Marston (IBM)

Regrets:
(LH) Lofton Henderson (CGMO)
(MS) Mark Skall (NIST)

Summary of New Action Items:
AI-20050131-1 (RK) to make it clearer what is meant by class of product  
(addressing the concerns of XML WG), 20050207
AI-20050131-2 (KD) to analyze "class of product" for XML ID, 20050202
AI-20050131-3 (LR) Review and modify wording on conformance, 20050211
AI-20050131-4 (KD) ask for more information on device-dependent  
profiles, 20050207
AI-20050131-5 (KD) to propose additions to error mechanism section,  
20050207
AI-20050131-6 (KD) to provide new wording for "write tests" in SpecGL,  
20050207
AI-20050131-7 (KD) to propose a "good practice" on the issue of  
formal/prose language normativity, 20050207

Agenda: http://lists.w3.org/Archives/Public/www-qa-wg/2005Jan/0075.html
Previous Telcon Minutes:  
http://lists.w3.org/Archives/Public/www-qa-wg/2005Jan/0051.html

Minutes:

1.) roll call 11am EDT, membership

2.) routine business
* Technical Plenary registration: please register!
http://www.w3.org/2002/09/wbs/35125/TP2005/registrants#qa
(kd) If you haven't registered, please do.

5.) SpecGL issues
Dom's analysis:
http://lists.w3.org/Archives/Public/www-qa-wg/2005Jan/0074.html

http://www.w3.org/Bugs/Public/buglist.cgi? 
query_format=specific&order=relevance+desc&bug_status=__open__&product=Q 
A&content=
* Classes of products unclear and dagenrous
(dh) A requirement only makes sense if applied to a specific class of  
implementation.
(dh) I don't think that classes of products are dangerous.
(kd) Can we produce a list of classes of products (a generic list)?
(dh) We have a list of sorts.
(tb) Is the nature of the comment that the current language unclear?  
Have we not captured the essence?
(dm) The complaint is that the explanation is unclear.
(tb) Is it possible to have XML Core WG clarify?
(dh) If we can provide a good list, we'd have a better explanation.
(dm) The obvious example (relating to XML ID) is a parser, we need a  
general category; something that handles a documents, when receiving a  
document the ID:s have not yet received the property of being the ID.
(dh) Send an email to the QA WG list.
(kd) We need to rewrite, make it clearer what we mean. Does someone  
volunteer to make it clearer for the XML people?
(rk) I volunteer, within a week
(kd) Send your proposal to the mailing list. AI: Analyze classes of  
products for XML ID by Wednesday

* Conformance is not a yes/no proposition
(dh) What I understand from Ian's email is that you cannot ever say  
that you are fully conformant to a spec; it's not a yes/no proposition.
(pc) Conformance is not binary. While it's not possible to claim with  
100% certainty that an implementation is conformant to every aspect of  
a specification, but rather as to whether the conformance _REQUIREMENT_  
has been met (for example, passing these tests etc). It's up to the  
spec writers to make it "binary" or easy to answer. We use the term  
conformanace in a special sense. If we require conformance in this  
sense, we need to rewrite specifications to meet this need.
(lr) To me, a conformance statement is a vendor declaration that they  
implement this or that feature.
(kd) [minuter: sound breaking up]... maybe we can add a clause to Spec  
GL ...
(dm) the ICS is also an input to the processor running the test
(lr) I'd say selecting the tests that are run. I'll take a stab at  
review and modify wording as necessary, by feb 11.

* Avoiding device-dependent profiles
(dh) Do we want to say anything about profiles being related to  
devices, or not?
(kd) We always try to say that the simpler the better (about the  
specification)
(tb) CSS has oral/visual features, for example
(lr) We have a statement indicating subdivision, on this point we need  
more information
(kd) I take the action item, since I've replied to his messages

* Additions to error mechanism section
(dm) Two kinds of ignore 1. pass through unchanged, 2 throw it away
(dh) should we add something to Spec GL? anyone volunteer?
(kd) I will. karl will make a proposal on this issue

* Additions to "write tests"
(dh) Mostly editorial, suggesting that an additional requirement is to  
go back an create tests for "old" sections, once they have matured. You  
also need to check interactions between tests, separate tests not  
enough
(tb) Do we want to recommend against having interactive assertions?
(dh) The idea of atomic assertions?
(tb) Right
(dm) That depends on the technology, for some technologies you have a  
necessary impact between things
(kd) The comment is good but a bit out of scope, it's about how to  
write good tests, not about Spec GL. We could add a line, not sure if  
we should change a lot of things. I take that action item

* Formal vs prose language normativity
(dh) Issue is that you shouldn't have to choose between the two when  
there is discrepancy. In some cases the formal language does not  
express as much as the prose
(dm) Lack of recognition that prose sometimes contradicts itself.  
Editors sacrifice readability for saying things only once.
(dh) David, any suggestions on how to deal with this?
(dm) Each WG has to decide on whether one statement can contradict  
another, otherwise fallback on errata procedures
(pc) It's more important that the spec be clear and precise, that the  
language be normative, rather than trying to provide guidelines for how  
people should use language. The spec needs to be clear, if something is  
required, it's required, if optional, optional.
(dm) How about if there is a tool, eg. formal notation, that says which  
one dominates in normativity and leave it to the WG to make the  
statement on normativity or not
(pc) We should not mandate use of language
(tb) WGs need too identify what parts are normative
(dm) Issue is what happens when two "normative" statements contradict  
each other and cover the same ground
(kd) Can we find examples where there might be ambiguity between prose  
and formal language?
(pc) If you have an inconsistency, you have a bug in the spec
(kd) The problem is that bugs happen, when the spec gets published it  
will contain bugs. How to minimize this? Some kind of error mechanism?  
If the two lanugages overlap, the one that is right is (I think we've  
said) the formal language.
(tb) That's the way most implementations are doing it
(kd) I agree with Ian. One technique would be to check the prose  
against the formal language. As an exercise before publication, each WG  
should check this
(kd) AI to propose a good practice on this issue

(dh) Telcon next week

Received on Wednesday, 9 February 2005 15:37:15 UTC