- From: Tim Boland <frederick.boland@nist.gov>
- Date: Tue, 10 May 2005 08:48:46 -0400
- To: www-qa-wg@w3.org
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 (W3C0
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 QAWG should 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
Received on Tuesday, 10 May 2005 12:50:55 UTC