Minutes for 20030707 telecon

QA Working Group Teleconference
Monday, 07-07-2003
--
Scribe: Sandra I. Martinez

(PC) Patrick Curran (Sun Microsystems)

(KD) Karl Dubost (W3C, WG co-chair) a
(PF) Peter Fawcett (RealNetworks) a
(LH) Lofton Henderson (CGMO - WG co-chair)
(SM) Sandra Martinez (NIST)
(LR) Lynne Rosenthal (NIST - IG co-chair) - a
(DM) David Marston
(AT) Andrew Thackrah (Open Group)
(DH) Dominique Hazaël-Massieux (W3C)
(MS) Mark Skall (NIST)


Guest:

(IJ) Ian Jacobs
(AR) Alex Rousskov

Regrets:

(KG) Kirill Gavrylyuk (Microsoft)


Absent:

(dd) Dimitris Dimitriadis (Ontologicon)


Summary of New Action Items:

AI-20030707-1   Dominique Hazaël-Massieux    CSS3 Basic UI Module    Due, 
July 21, 2003


Agenda: http://lists.w3.org/Archives/Public/www-qa-wg/2003Jul/0013.html

Telcon Minutes: [...replace w/ correct link before circulating...]
[Optional: previous f2f minutes if one just preceded telcon]

1.) roll call 11am EDT, membership

2.) Any routine business
- Reviewer for CSS3 Basic UI Module [0]? - Review was assigned to Dominique.
- Overdue Action Items  -- skipped.

3.) Resolved-to-Closed endorsement (default)
- (Is 1 week acceptable for the process?)
- OpsGL package ... [1a], [1b]


(LH) : propose to move to next week teleconference.  - A week will be 
sufficient to review. If no comments are reported they will be considered 
close.



4.) LC-issues [3]

LC-67 part 1 [5]

(LH) We have three suggested alternatives for this issue. There is not a 
single correct way that we can define or address all environments. The 
alternatives capture the main ideas. We want to promote the RFC keywords. 
Must all conformance requirements use RFC2119 keywords? There it could be 
other alternatives, different variations. Not clear why Ian chose a hybrid 
method.
I will like Ian to help understand.

(IJ) : The HTTP specification uses the RFC key words to reach two 
conformance levels; the unconditionally compliant and the conditionally 
compliant. We have more profiles than that, we have more granularity, RFC 
key words enables
only one conformance level; the must requirements. Also UAAG uses the 
imperative voice to express the requirements, so the "MUST" is usually 
implied, it was also easier to read.

(MS) : When things are equally recognized as a requirement, by using the 
keyword it will be easier to recognized, specially for people that are not 
familiar with the specification.

(IJ) : When I started writing, I was concerned about readability.

(MS) : We are back to a philosophical argument.

(IJ) : In UAAG, A/AA/AAA was not going to suffice. It should be a strong 
recommendation to use the standard terms, but allowing leeway.

(LH) : Alternative 3 proposes a rewording of the conformance requirements 
with four requirements to capture the idea that you must use RFC keywords, 
or some equally clear and unambiguous method and a requirement to also find 
a relationship between the alternative method and the RFC keywords.
The second bullet could be a "should". Also, the method chosen should be 
documented and we can point to the UAAG in the Examples and Techniques.

(IJ) : Adding a statement explaining the choice.

(LH) : It is a judgment call where to put the justification for using an 
alternative to RFC 2119. The alternative chosen (1, 2 or 3) could be in the 
conformance clause or terminology sections.

(LR) : It should be somewhere in the specification, the conformance clause 
is a possible place.

(MS) : It must be in the conformance clause.

(IJ) : CP 13.2 focus is on the identification of requirements and the need 
to be clearly identified and distinguished.

(AR) : What is the difference between normative and conformance requirement?

(LF) : You can have declarative text identified as normative.

(AR) : If it affect conformance, it should use RFC keywords.

(DM) : Alternative 3 propose that every specification must address the
    use or not use of the RFC keywords.

(LH) : The difference between alternative 2 and 3 is the requirement of
    why using or not and the use of mapping.

(MS) : - There is nothing about justifying in the alternatives.

(LH) : My mistake for not reading the thread.

(MS) : Justifying why you are not using the keywords should be addressed.



LC-70, reformat checklists [2]

          Ian left the meeting.

(LH) : This one applies to OpsGL, SpecGL, and TestGL. Basically, calls for 
a redesign of the layout and content of the checklists.  The proposed 
changes of "Yes No N/A" to "Yes No N/A Pending" go beyond formatting.

(LR) : We need to clarify the purpose of the checklist; the original intent 
was not to be use as an ICS.

(LH) : Our response should be a clarification of the purpose. The rest of 
the formatting suggestion falls apart.



Ungrouped issues [4]

(LR) : I did not see any contention here.

(LH): We should task everyone to go over these issues and comment. If no 
strong feelings are raised, the editors will handle them. I do have some 
questions, 29.3 is not easy to understand, I am not clear how this affects 
the SpecGL, he is talking about something different.

(LR) : This issue should not be address in this version of the SpecGL.

(DM): This could be a pressing issue in some user oriented areas like 
Xpath, Schema, etc.

(LH) : We need to draft a response to why this is not applicable to SpecGl, 
at this time. Any comment or concern on this issue should also be raised.


6.) 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 Monday, 7 July 2003 16:19:45 UTC