"WeekinQA" is a monthly (started bi-weekly, hence the name) 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 "WeekinQA" is Lynne Rosenthal, NIST, co-chair of the QA Interest Group.
See also the initial calendar and initial requirements for this resource.
The QA Activity published two W3C Notes: CHIPs is a set of good practices to improve implementations of HTTP and related standards as well as their use; iCUAP explains some common mistakes in user agents and suggests remedies. So far, comments have been received on the CHIPs checkpoints that talk about URIs - it seems that in W3C since there is little control over where a NOTE goes, the CHIPs URI violates some checkpoints. So, "do as we say, not what we do". Other comments, include ETag (i.e., equal ETags do not imply equivalent resources) is being investigated and a suggested improvement to the W3C server for Content-Location, (i.e., follow CHIP checkpoint 5.2.II, Content-Location: of the dated version) - this has been added to the webmaster's "todo" list. With respect to CUAP, there was an interesting discussion about user agents saving files as "filename.ps.gz " (Content-Type: application/postscript, Content-encoding:gzip). The discussion concluded that a users doesn't need gunzip and that if UA can save and render a compressed document, the same UA should be able to open it again. Comments and suggestions on these Notes are welcome and should be sent to: www-qa@w3.org.
See Threads:
Although comments from the public are often requested and always welcome, it is important to ensure that all the public comments are taken into account. Concern was expressed that the public has no power of appeal when the W3C Process for handling public comments is not followed. To gain the maximum advantage from the knowledge and insights of all who take the time to read and comment on the documents, they (the public) needs to believe that they are being listened to. Possible solutions? Notify individual commentors of the disposition of their comments and ask them to indicate their acquiescence or opposition with regard to this disposition. Use a "bug database" like Bugzilla to keep track of issues, their disposition, and WG-individual contact. Post issue resolution information on their public webpages. What does your WG do?
Last autumn, the QA WG asked W3C Chairs and their document editors what document technologies they used to edit their specifications. The purpose of this survey of authoring technologies was to determine whether there is a set of common tools and techniques that might help authors, and that might warrant further QAWG attention. Results of this survey indicated that most people used either XML Spec or XHTML+classes. Within each of these two technologies, there was some customization e.g., modification to match namespace constraints, customization to allow additional structured information, custom elements to markup references, etc. It was clear that XML, where used, was not judged to be sufficient for all authors. Future versions of XML Spec should look into the changes made by some WGs to accommodate for those customizations. The major reason cited for not using XML Spec was ease of authoring and not knowing about XML Spec. As for editorial tasks and the publishing process, it seems that most lead editors assemble the document parts, although other variants and combinations exist (e.g., assembling document parts from CVS, transforming into master version for publication and so forth). Looking at this data, it may be beneficial to streamline the editing process.
See Threads:
The QA Framework: Operational Guidelines checkpoint 6.4 regarding conformance disclaimers was clarified. A conformance disclaimer explains the relationship between test suite results and conformance. The objective of a conformance disclaimer is to help users of the test suite and consumers of test results understand that passing all tests in the test suite does not guarantee or imply full conformance of an implementation to the specification. Basically:
A conformance test suite can never prove conformance, it can only disprove it.
