Issues regarding the documents produced by the QA Working Group should be reported to www-qa@w3.org (public archives).
Comments on this list should be sent to the www-qa@w3.org mailing list (Archives).
num | Status | Spec | Topic | Class | Date | Title |
---|---|---|---|---|---|---|
69 | Active | SpecGuide | SpecGuide | Substantive | 2001-05-29 | Should Spec Guidelines discourage "flavors of conformance"? |
num | Spec | Date | Topic | Class | Status | Raised By | Owner |
---|---|---|---|---|---|---|---|
1 | IssueList | 2001-12-20 | IssueList | Editorial | Closed | Mark Skall | |
Title: How should QA Issues be managed and tracked? | |||||||
Description: [email] This was raised and discussed at Brussels f2f, 11/2001, without clear resolution. Bugzilla was discussed at that meeting. Another proposal (Henderson & Gavrylyuk): Maintain them in a simple XML grammar that can be XSLT-transformed into tabular or other document format (SOAP and DOM do this). Alternative (Henderson): SVG has a simple method, that seems to be based on a simple plain text master document, http://www.w3.org/Graphics/SVG/Group/issues.txt, which has very little prose text and relies mainly on references to the mail archive. Other alternative, to use SourceForge (per DOM-TS) was proposed at the 2001-12-06 QAWG teleconference. Discussed and finally resolved at 2001-12-20 QAWG teleconference. | |||||||
Proposal: | |||||||
Resolution: Use simple XML/XSLT scheme, similar to SOAP and DOM. | |||||||
2 | IssueList | 2001-12-20 | WG-process | Editorial | Closed | Lofton Henderson | |
Title: How should issues be identified or numbered? | |||||||
Description: What do we want for an issue number scheme? Alternatives: no number, use a mnemonic name, such as "issue-number-scheme"; or, simple ordinal numbering 1, 2, 3, ...(SVG does this); or, year and number 2001-1, 2001-2, ... | |||||||
Proposal: | |||||||
Resolution: Have simple ordinal 'issue-num' plus meaningful 'id'. | |||||||
69 | SpecGuide | 2001-05-29 | SpecGuide | Substantive | Active | Dan Connolly | Lofton Henderson |
Title: Should Spec Guidelines discourage "flavors of conformance"? | |||||||
Description: [email]
In the FPWD (2002-05-15) of Specification Guidelines, there is no
language in
"Guideline 3. Specify flavors of conformance." indicating that
options/levels/flavors are bad. Originator proposes that there should be.
It was discussed some
in the email thread, without resolution.
Discussed at 2002-05-30 telcon. Discussed at Montreal face-to-face (6/2002), without definitive resolution. However, there is general agreement that excessive variability hurts interoperability. The problem is: how to quantify it. It was agreed to move forward by reorganizing SpecGuide according to DM email proposal. This in turn will be the basis for further input from WGs and continued discussion on the IG list. The specific proposal for a checkpoint to limit to 3 dimensions was discussed but not accepted -- too inflexible to fit all sorts of W3C specs. See related issue #70 |
|||||||
Proposal: Originator proposes that minimizing (esp. zero) flavors should be a design goal for all W3C specs. | |||||||
Resolution: | |||||||
70 | SpecGuide | 2001-05-29 | SpecGuide | Substantive | Closed | Lofton Henderson | Lofton Henderson |
Title: Spec Guidelines needs a specific enumeration of "flavors of conformance". | |||||||
Description: [email]
The email thread indicates that there are widely differing
understandings of what is meant by "flavors of conformance" in
"Guideline 3. Specify flavors of conformance." of the FPWD
(2002-05-15) version of Specification Guidelines. Before it can
be argued whether flavors are good or bad, the statement of the
guideline needs to be clarified. It needs a specific enumeration of all of the
sorts of flavors to which it applies. So far, only "Strict
Conformance", "Unconditional Conformance", and "Conditional Conformance"
are mentioned.
Discussed at 2002-05-30 telcon. See DM email proposal. This proposal was discussed Montreal face-to-face (6/2002). It was agreed to reorganize the SpecGuide document accordingly, in which case the "flavors" go away, a complete enumeration of "dimensions of variability" affecting conformance in specs is implemented, and "flavors of confomance" GL becomes a "conformance policy" GL. See related issue #69 |
|||||||
Proposal: | |||||||
Resolution: As decided at Montreal (see above). |