Final Minutes 9 May 2005 QAWG Teleconference

QA WORKING GROUP TELECONFERENCE MINUTES
Monday 9 May 2005


SCRIBE: Tim Boland


ATTENDEES:

(MS) Mark Skall (NIST)
(KD) Karl Dubost (W3C, Chair)
(TB) Tim Boland (NIST)
(DD) Dimitris Dimitriadis (Ontologicon) (only for agenda item 4)
(LH) Lofton Henderson (CGMO)
(LR) Lynne Rosenthal (NIST)
(RK) Richard Kennedy (Boeing)
(PC) Patrick Curran (Sun Microsystems)
(DH) Dominique Hazael-Massieux (W3C)



REGRETS:



GUEST:

(DM) Dave Marston (IBM)



ABSENT:



SUMMARY OF NEW ACTION ITEMS:

AI-20050905-01: (General) KD to reply to responders with QAWG decisions re: 
Issues
under Item 3 ("Answers to Answers Review") following by next teleconference
AI-20050905-02: DM to take Al Gilman wording and add erratum recommendation 
sentence
(as described previously) by Wednesday.
AI-20050905-03: LH will propose a technique regarding deprecation before 
Version 1.0
in one week's time
AI-20050905-04: DH to rewrite last paragraph of ICS introduction to make 
clearer
(addressing concerns raised)
AI-20050905-05: DH to draft answer on Issue 1158 in one week's time
AI-20050905-06: DD to send out intro section of SpecGL Implementation Report
for MS review by Tuesday
AI-20050905-07: DD will post draft of SpecGL Implementation Report by 
Wednesday
afternoon
AI-20050905-08: KD to produce SVG Tiny Implementation Report in one week's 
time
AI-20050905-09: DD will integrate KD SVG Tiny Implementation Report
into SpecGL Implementation Report when SVG Tiny Implementation
Report is received.
AI-20050905-10: PC by Friday to post revisted TestFAQ to list
AI-20050905-11: TB to submit redrafts of WAI CG QAWG Responses re: SpecGL
this week to list.



AGENDA:
http://lists.w3.org/Archives/Public/www-qa-wg/2005May/0017.html



PREVIOUS TELECONFERENCE MINUTES (DRAFT):
http://lists.w3.org/Archives/Public/www-qa-wg/2005May/0007.html




MINUTES:


1) ROLL CALL



2) ROUTINE BUSINESS

PC has nothing new to report on preparations for Dublin f2f



3) ANSWERS TO ANSWERS REVIEW


ISSUE 1049

KD moved ISSUE 1049 to first issue under discussion, because it was felt to
be the "most difficult" issue to discuss.

Ian Hickson disagreed with the QAWG proposed resolution: the response to the
proposed resolution stated that if there was conflict in a specification of
this nature, then an erratum has to be published.
DM felt that this viewpoint was too idealistic, and bad for developers (would
keep developers "in suspense" and drag out development); DM felt
that the WG issuing the specification should have the ability to make
  a "preemptive" statement on this matter.
PC agreed that the right thing may be to produce errata to resolve such 
conflicts,
and that possibly a recommendation to produce errata in such instances may be
appropriate. DH suggested that maybe some text should be added to the effect
that, when there is such a discrepancy on formal vs. prose, the WG should 
publish
an erratum, but that it would be good to have an interim "tie-breaker" for the
reasons mentioned previously. KD stated that conflicts are not acceptable,
and publishing errata to resolve conflicts should be encouraged. TB raised
concern about conflict vs. error in this regard. LH likes the
wording from Al Gilman on this matter as a base, and then
add a sentence strongly recommending (in non-normative language) to publish
errata when inconsistencies of this nature arise. KD also suggested pointing
to the part of the W3C Process Document which addresses errata in this 
sentence.

ACTION: DM to take Al Gilman wording and add erratum recommendation sentence
(as described previously) by Wednesday.

ACTION: KD to send reply to Ian Hickson (re: previous on this issue) in one 
week's time



ISSUE 1048

1048 - Ian Hickson accepted the QAWG proposed resolution, but encouraged 
different
wording to the QAWG. After some discussion, the QAWG accepted Ian's suggested
different wording.

ACTION: KD to send reply to Ian Hickson (re: previous on this issue) in one 
week's time


ISSUES 1151, 1143, and part of 1158

The QAWG proposed resolution was accepted partially, but a requirement 
rewording was
proposed . IN response to this, DH stated that, using DAML+OIL
as an example, having a Version 1,0 doesn't necessarily mean that there is 
never a
previous "version". Discussion ensued as to whether to reword the requirement
as Chris Lilley wants. Several issues arose in this context.
Should the QAWG include text concerning the rare cases where a Version 1.0 
has a
previous "version" (including relevant deprecation issues?). DH suggested 
addressing
cases of "previously well-deployed specification" effects
re: deprecation?. Discussion then centered around
the meaning of deprecation in relation to versioning; before a standard 
exists, how
can deprecation occur? LH suggests using "characteristic" of deprecation. 
KD stated
that a precursor technology could define features that are carried forward 
into a
Version 1.0, but warnings may be given to remove such features in the next 
version. Perhaps
this scenario should be given some other name besides "deprecation"?
DH suggested not to try to solve the general problem in this regard at this 
time;
the focus at this time is to thank the commenters, to respond with 
individual feedback, and
to find the "right balance" in the feedback. DM thought that the problem 
was solvable
if wording omitted specific references to Version 1.0. Perhaps a change in 
terminology
should be made to "technology that has been previously specified"?
LH wants to include a sentence as an "informative" note later stating that 
in rare cases
reference to precursors of Version 1.0 (or something similar?) can occur in 
the context
of deprecation. DH also proposed adding a technique
concerning this item.

After much discussion, the QAWG agreed with Chris Lilley on a slight 
rewording of the requirement
to make deprecation before Version 1.0 possible.

ACTION: LH will propose a technique regarding deprecation before Version 
1.0 in one week's time
New wording was also proposed for Requirement 12. DH felt it was better to 
keep requirement
as it is.

ACTION: KD to send reply to Chris Lilley (re: previous on these issues) in 
one week's time.


ISSUE 1050

There will be no change in the proposed QAWG resolution on this issue. DH 
disagrees with the
expressed concerns.

ACTION: KD to send reply to Ian Hickson (re: previous on this issue) in one 
week's time


ISSUE 1157

Chris Lilley accepted the QAWG proposed resolution, but wanted clarity on 
which columns
should allow linking in the ICS (the "yes" column or the "comments" 
column). DH
referenced as an example SpecGL on ICS, to indicate proper linking in this 
regard.
LR expressed a concern that linking from "yes" column may confuse people or 
imply that
all tests are passed pertaining to that entry (also referencing previous 
discussions
on what an ICS is). After some discussion, it was felt that links from 
"comments"
and "yes" columns might be appropriate.

ACTION: DH to rewrite last paragraph of ICS introduction to make clearer 
(addressing
concerns raised)

ACTION: KD to send reply to Chris Lilley (re: previous on this issue) in 
one week's time


ISSUE 1158

On Point 7, Chris Lilley suggested rewording. DH questioned whether 
publishing a new version is
"extending" it ("versioning" and "extensibility" may not be the same?), and 
felt that the
expressed concerns were out of scope for the QAWG. MS raised a query as to 
scope of
extensibility mechanisms (how limited?). DH mentioned the definition of 
"extensibility"
and "extensible" in the context of this discussion. It was felt that the 
TAG was addressing
higher-level questions of extensions on the web in general, instead of 
specifically focusing
on "local" extensions. KD also rejected the concerns as out of scope of SpecGL.

ACTION: DH to draft answer on Issue 1158 in one week's time.

ACTION: KD to send reply to Chris Lilley (re: previous on this issue) in 
one week's time




4) SpecGL IMPLEMENTATION REPORT

DD has written a (terse) introduction to the SpecGL Implementation
Report. MS agreed to review the introduction to make it more
readable and verbose. The SVG Mobile Implementation Report left
out Section 3 of the SpecGL template (due to temporary omission
in original template), but the QAWG felt that the report should be included
anyway. KD will produce an implementation report on SVG Tiny.

LH thought the SpecGL Implementation Report should include a matrix;
other QAWG members felt this was a good idea.

ACTION: DD to send out intro section of SpecGL Implementation Report
for MS review by Tuesday

ACTION: DD will post draft of SpecGL Implementation Report by Wednesday
afternoon

ACTION: KD to produce SVG Tiny Implementation Report in one week's time

ACTION: DD will integrate KD SVG Tiny Implementation Report
into SpecGL Implementation Report when SVG Tiny Implementation
Report is received.



5) OTHER BUSINESS


Concerning TestFAQ, PC has finished editing, with one change yet to make.
ACTION: PC by Friday to post revisted TestFAQ to list

DM's submission ("Proposed Additions to Variability in Specifications")
to the list will be discussed at next Monday's teleconference. KD 
encouraged all
members to read the submission in preparation for that discussion.

TB sought clarification on redrafts of WAI CG SpecGL QAWG Comment
Responses. DH comments to TB will be incorporated into redrafts.
KD wanted the responses separated per individual issues in draft.

ACTION: TB to submit redrafts of WAI CG QAWG Responses re: SpecGL
this week to list.

The next teleconference will be held on Monday, 16 May 2005.



MEETING ADJOURNED