"MonthinQA" is a monthly summary of the main topics discussed on www-qa@w3.org, the public mailing-list of W3C QA Interest Group and www-qa-wg@w3.org, the public mailing-list of W3C's QA Working Group.
The regular editor for "MonthinQA" is Lynne Rosenthal, NIST, co-chair of the QA Interest Group.
See also the initial calendar and initial requirements for this resource.
The QA Operational Guidelines (OpsGL) has been published as a Candidate Recommendation, or "CR". During the CR period, the QAWG seeks WGs willing to apply the guidelines to their process. By applying, we don't mean "comply", but rather to go through the OpsGL checklist and let the QAWG know what they think they already do, what they expect to do in the future, and what they don't expect to do. Additionally, any feedback regarding the implementability of the checkpoints is welcome. The CR period will end on 27 February 2004, just before the next Technical Plenary Meeting in Mandelieu, France.
The QA Operational and Test Guidelines advocate publication of test results. The WebOnt WG is using RDF to manage their test results. EARL can also be used to manage test results. This email thread discussed the differences between these two approaches. Some of the differences includes: EARL doesn't include a specific property for duration as a values of the test result although this could be done via the general comment property; EARL includes more types of results (e.g., description of the way something was tested); and provenance is built into the EARL model. There may be trade-offs here: EARL may not be the simplest and easiest thing to use, you may not need to handle provenance or some of the other features of EARL. But one consideration should be - that by using the same reporting facilities we can promote interoperability, consistency, and reuse rather than reinvention.
In another related thread were comments on reporting % of tests passed. Issues about percentages include: the implication that the test suite is 100% complete and won't be expanded and the implication that all tests are counted equally. On the other hand, many of us use percentage of tests passed as a measurement of our improvement, i.e., when we first ran the suite we pass 80% and now, we pass 99%. Caution should be used when reporting percentages.
Although URIs in principle are opaque, (don't infer anything from the characters used in the URI), it is a good idea to make URIs readable. It is a good idea to make short, intuitive, and implementation-independent URIs. This way they are easier to remember and to type when its not possible to follow hypertext links, it also can help minimize the use of search engines.
Interested in URIs? You may also want to read: Cool URIs don't change
The next face-to-face is scheduled for 21-23 October 2003 in Boulder CO at NIST, Boulder. QA IG participants are wlecome to join, provided they contact the WG and IG chairs in advance. Due to Security at NIST, all visitors will need to pre-register. See the logistics and agenda for more information.
Don't forget to check out the latest QA News: including the newest items: "RDF makes it easier" and Newer version of "Think Globally, Act Locally" released.
All meeting minutes are available at: http://www.w3.org/QA/Agenda/
