- 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