W3C home > Mailing lists > Public > www-qa-wg@w3.org > April 2003

Final Minutes of QA WG Teleconference 2003/04/10

From: Sandra Martinez <sandra.martinez@nist.gov>
Date: Wed, 23 Apr 2003 10:30:05 -0400
Message-Id: <>
To: www-qa-wg@w3.org

QA Working Group Teleconference
Thursday, 10-April-2003
Scribe: Sandra I. Martinez

(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)
(SM) Sandra Martinez (NIST)
(LR) Lynne Rosenthal (NIST - IG co-chair)
(MS) Mark Skall (NIST)
(AT) Andrew Thackrah (Open Group)
(DM) David Marston

(PF) Peter Fawcett (RealNetworks)

(dd) Dimitris Dimitriadis (Ontologicon)
(KG) Kirill Gavrylyuk (Microsoft)

Summary of New Action Items:

AI-20030410-1:  Patrick and Peter               Send e-mail with proposed 
schedule for TestGL publication dates the
                                                 TestGl. Due: Apri 11

AI-20030410-2:  Lynne                           Provide appropriate wording to
                                                 combine CP 1.2 and 1.3. 
Due: April 18

AI-20030410-3:  Lynne                           Revise use of obsolete 
example in
                                                 HTML and draft something 
to reflect
                                                 what needs to be done for 
issue LC-40
                                                 (Relationship between obsolete
                                                 and deprecation). Due by 
April 18.

AI-20030410-4:  David                           Re-draft and include a 
rationale to reflect what was discussed for issue
                                                 99. Due April 18

Agenda: http://lists.w3.org/Archives/Public/www-qa-wg/2003Apr/0049.html
Previous Telcon Minutes: 


1.) roll call 11am EDT, membership

2.) Spec Guidelines [1]
     Last Call SpecGL issues [3], groupings [4]

"Originated during 20030407 telecon, during discussion of issue #92. 
Discussion: It is unclear what is the difference between CP 1.2 and CP 1.3, 
according to their respective stated rationales. Is CP 1.3 a superset of 
CP1.2? Can they be combined? Do we need both? If we need both, then what 
purposes are the "usage scenarios" of CP1.3 serving that are distinct from 
the purposes of CP1.2?"
LR:      initiated the discussion by restating the issue and pointed to an 
e-mail sent by Lofton where he explains that this issue has a background in 
previous issues.

LH:     It is unclear why it was determined that use case applied to one CP 
and usage scenario to another. The rationale of the two CPs 1.2 and 1.3 
seem to have merged. We agreed to reword 1.2 to illustrate scope and let 
1.4 addresses the functional details.
SM: Issue 109 is referring to a distinction between CP 1.2 and CP 1.3.

LR: Yes, the first thing we need to address is the distinction between the two.
MS:      I agree with Lofton. I remember this the previous discussion on 
this issue and there is no reason why this one CP is referring to use case 
and the other to usage scenarios. They should be combined. It is too subtle 
a difference.

LH:     They should be combined but it should also emphasis the use of use 
cases and user scenarios as a valuable technique.

LR:     OK! I will come up with the appropriate wording to combine CP 1.2 
and 1.3 and also provide wording for user scenarios as a valuable technique.

Other issue processing per [2]

Lofton asked about issue 77.ET-2, which deals with levels of examples. This 
issued was discussed in a previous meeting (Monday 7 April). KD added that 
his intention was for CP to have examples.

LC 33, 40, 99:
LR:     Issue 33 is purely editorial there is no need to discuss. On issue 
40, adding the idea of obsolete feature. I am not sure that we want to 
include obsolete as an additional alternative.

LH:     I think the original intention was that deprecation encompassed 
obsolete features.

MS:     First we need to clarify if there is a distinction between obsolete 
and deprecation.

LR:     Exactly. Lofton sent an e-mail regarding this issue, followed by 
David response.
DM:     I am not sure if the meaning we are giving to obsolete is the same 
Ian is referring to in the HTML 4.0 example.

SM:     The dictionary defines obsolete as no longer in use or no longer 

DM:     The question is whether obsolete means deprecation or removal?

PC:     Stick to deprecation, explain the term better and get rid of obsolete.
LH:     That was not my understanding. I thought deprecation encompasses 
obsolete. Also, the dictionary does not imply removal, it is almost like 
one step up to deprecation or removal.

LR:      We need to put a definition in definition Section.
LH:     Did someone looked at the HTML example? Is there a distinction 
between deprecated, removed and obsolete?

PC:     I will think that when a feature is deprecated it means that the 
feature will still be there, but that at some point, it will go away. 
Obsolete, means that everybody should stop using it.

MS:     A deprecated feature is on the road of being remove, but what is 
the criteria to become obsolete?

LR:     I will look at the use of obsolete in HTML and draft something  to 
reflect what needs to be done and I will forward to the group for 
debate.  I will also talk to Ian for clarification, if needed. I don't see 
closure to this issue yet. Any Objections?

LR:     If no objections, lets move on to issue 99. The issue deals with 
the relationship of deprecation and its relationship with other dimensions 
of variability. Lofton sent an e-mail on this issue.

DM:     and I agree with Lofton e-mail.
LH:     The commenter is assuming that "defines," means fully defining the 
deprecated feature. He has misinterpreted what is meant in the checkpoint

PC:     Where it gets us, is in the concept of deprecation and level of 
LH:     If a feature has been deprecated because it is basically poorly 
defined or cannot be defined, it is still possible for the specification to 
address how the deprecation of the feature is related to DoVs.

DM:     If a deprecated feature is associated with a module or a particular 
profile we should make that clear.

LR:     This is all related to conformance consequences. We are getting one 
level deeper from the previous checkpoint.

LH:     The email is to abstract we need to add some examples using David 

David agrees to re-draft and include a rational to reflect what was discussed.

LC-36, 65, 106, 108

Comment about "Overall": Is the glossary normative?

LR:     It is unclear which sections, paragraphs, and sentences are 

LH:     What about Ian question. Is the glossary normative?

LR:     Section 4 or the glossary?

LH:     Both. See his e-mail he sent an example of normative in glossary.
LR:     I consider the definitions in Section 4 normative. It Will be 
helpful if we follow the Accessibility GLs and label all sections, as is 
normative or not.

LH:     What about 1.1 or priorities are they normative? Take the difficult 
ones. I agree with you it is a good idea, but we will take a lot of time 
agreeing, just take the example of priority. It is not trivial.

LR:     Make sense. Can we just label some of them?

PC:     Not a good idea. All comes down to the language.
LR:     Going back to section 4. Is it normative? Maybe our definition of 
normative is wrong. We need a new definition.

PC:     I believe Section 4 is informative

MS:     By definition glossary is informative.
LR:     We just decided the glossary and the definition informative 
sections are both informative.

LH:     We should generate an action for someone to write Ian to ask for 
comment on our resolution for this issue.

LR:     We are comfortable with the definition section.

LH:     I am not entirely convinced. We need to get buy-off.
LR:     If we go to Ian as you suggest, we will be giving special 
treatment, which implies going back to all the commenter.

LH:     This one is more controversial.

MS:     We should be consistent. I agree with Lynne, this could go on forever.

KD:     As part of the process in resolving the issues, We need to go to 
each individual and have a dialog with them regarding the resolution of the 
comments and their agreement with the resolution.

DH:     Agreed. Is better to have each individual agree.

LH:     Do we have a response to 108?

LR:     No response for 108 yet.

LH:     We should start with 108 in our next meeting.

LR:     Thank everyone for your time and input.

3.) Adjourn

Sandra I. Martinez
National Institute of Standards and Technology
100 Bureau Drive, Stop 8970,
Gaithersburg, Md. 20899

(301) 975-3579
Received on Wednesday, 23 April 2003 10:30:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:30 UTC