- From: Sandra Martinez <sandra.martinez@nist.gov>
- Date: Wed, 23 Apr 2003 10:30:05 -0400
- To: www-qa-wg@w3.org
QA Working Group Teleconference
Thursday, 10-April-2003
--
Scribe: Sandra I. Martinez
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)
(SM) Sandra Martinez (NIST)
(LR) Lynne Rosenthal (NIST - IG co-chair)
(MS) Mark Skall (NIST)
(AT) Andrew Thackrah (Open Group)
(DM) David Marston
Regrets:
(PF) Peter Fawcett (RealNetworks)
Absent:
(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:
http://lists.w3.org/Archives/Public/www-qawg/2003Apr/0189.html
Minutes:
1.) roll call 11am EDT, membership
2.) Spec Guidelines [1]
Last Call SpecGL issues [3], groupings [4]
LC-109:
"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
useful.
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
variability.
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
clarification.
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
normative.
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
sandra.martinez@nist.gov
Received on Wednesday, 23 April 2003 10:30:40 UTC