"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.
Discussions continue with Joseph Reagle regarding which W3C License (Software, Document, other?) should be used for test suites. The question was raised because some test suite adaptations are desirable (e.g., to create a language specific implementation of an abstract binding), while others (e.g., exculsion or alteration of an actual test case) are not. Issues of concern include: warranty and liability, i.e., having appropriate/relevant disclaimers; scope of use; redistribuiton; and modification and adaption. From the discussions, it may make sense to use a combination of the present licenses and/or a new FAQ exception to handle these concerns. For example, if the test suite consists of test cases, test documentation, and test software (e.g., harness, abstract bindings), then test cases under the Document License would be able to preserve their integrity for purposes of claiming conformity and test software under the Software License would allow for adaption to a local environment. No conclusions have been made as yet and the discussion continues.
Did you ever wonder if there were any restrictions on the use of the validation icons? Can you incorporate them on your web pages? Yes, you can.
The icons use is explained in the logo usage policy. In particular, the icons are covered by the W3C trademark license. Basically, this means that use of the icon is free, copying and distributing is OK, modification is not allowed.
Thanks to Philippe Le Hegaret, there now is a tool that shows the DOM support claims of an HTML user agent, an XHTML user agent, and an XHTML, SVG and MathML user agent.
Recently, the IETF's Internet Architecture Board published an Internet Draft entitled, Guidelines for Writing RFC Text on Security Considerations and is requiring that all RFCs include a Security Considerations section. This document may be of interest to WGs who may want to include security considerations in their specifications.
