W3C creates the technical specifications regarded by the Web Community at large as Web standards. In order for these standards to permit full interoperability and access to all, it is very important that the quality of implementation be given as much attention as their development.
As of the beginning of 2001, W3C has published more than 20 Recommendations. As our family of specifications get more complex, their acceptance and deployment on the market becomes an ongoing challenge. The past experiences of HTML, CSS or more recently SMIL (all implemented with various degrees of conformance by vendors) are strong incentives to start this activity with due diligence.
A message related to formalizing our work on QA at W3C was sent to w3c-ac-forum@w3.org in 1999 by Daniel Dardailler. The initial feedback from AC members on this list was very positive and led us to hire a Conformance Manager (Karl Dubost) whose role would be to organize and lead this activity.
This briefing package proposes such an activity, with a focus on solidifying and extending current practices (existing validation tools, test suites, common test framework, etc) and thinking ahead in terms of certification, education, funding, and tracking the quality of products and services related to W3C technologies.
We therefore propose the creation of a Working Group focused on building test tools and of an Interest Group to share ideas on on using these tools.
There has always been and still is a strong demand from the Web community (end-users, Web agencies, organizations, software developpers, etc.) for better support and better implementation of W3C Specifications in products (commercial or not).
All Web users have at one point or another experienced the problem of invalid pages rendered incorrectly ontheir platform or valid pages rendered incorrectly by their platform.
Most experienced Web authors have at one point or another been faced with the choice of either developing several versions of a page or picking up one particular solution detrimental to a portion of their audience.
The overall mission of a QA team at W3C would be to improve the quality of W3C specification implementation in the field. In order to achieve that, we will need to
Fortunaly enough, we're not starting from scratch in this area.
QA is absolutely necessary in order to ensure interoperability and
usability and also to have consistency between the specifications we produce.
The QA Activity will benefit to the Web community, to the Industry and to
Members, as a guarantee to have interoperable products, which is the core
mission of W3C.
@@will also mention in this section the result/finding of the W3C QA Workshop at NIST on April 3-4 2001
QA applies to all W3C activities. The QA activity itself will therefore not be attached to a particular W3C domain but will exist independently as a cross domain activity.
The Quality Assurance Activity is dedicated to all aspects concerning the
quality of the implementations of W3C specifications in
products (commercial or not) as well as the quality of the documents
we produce. W3C wants to improve the level of interoperability of software
used to access (read/write) and serve the Web.
The activity should help the implementations of the W3C Recommendations with
tools such as validators and test suites. The activity will strongly encourage
working groups and/or third parties to produce test suites. It should also
focus on the quality of documents produced at W3C, the consistence of these
documents, and to ensure level of conformance are well defined in our
Recommendations.
The activity will cover:
The QA Activity leader is Karl Dubost <karl@w3.org>
The QA Activity will begin with two groups: a Working Group on tools production and an Interest Group on certification/branding/education/documentation.
The Activity home page will be http://www.w3.org/QA/
The duration of the activity is initially set to two years.
The Working Group will help organize and unify the work done in W3C groups in building and designing test suites and validation tools. It will also define the terms of QA, using a glossary, a taxonomy file, and also create a "how-to" guidelines to build test suites.
The objective of the working group is to foster the development of usable and useful test suites for the W3C, sharing a common look and feel and IPR terms, and ensure that the validating tools of the W3C are fully operational, useful and educational.
As a step in performing this task, the QA Tools Working Group will need to work on conformance testing methodology, on the quality of the W3C specifications wrt to conformance and clarity, and the tracking of issues related to specification ambiguity and evolution.
Its main deliverable will be the maintenance of the QA Matrix and the evolution of tools associated with W3C technologies.
@@link to proposed WG charter later on
The Interest Groupmain objective will be to have W3C, its membership and the Web community involved in QA at large share their understanding of the state of affairs related Web certification, branding, educational effort, funding model, etc.
Certification and branding appears to be a keypoint in many organizations and governmental agencies. It helps the customers to identify the tools that produce documents of quality and it applies to browsers, as well editors, software libraries, webservers, etc. As of the writing of the proposal, certification is considered outside the scope of the activity but we'll need to clarify what a certification system should do, who should run it, and how to interface with this market.
Although not a core activity of W3C in general (except in the WAI domain), we think education and documentation are a necessity to reach the level of quality we want to see in the implementation of our standards. To start with, many Web developers, technical writers and/or software developers have no ideas what is the W3C standard, what is a W3C standard and why it is important for them. The QA Activity will need to work in cooperation with communication service to promote the awareness of standards, tools to check them and the rationales for using them.
@@link to proposed IG charter later on
We expect the two groups and the activity resources in general to be publicly accessible.
All documentations, test suites, validating tools produced inside this activity will have to be defined under a license. There are questions about the kind of license to use (for instance we have two licences at W3C: one for document and one for software, the document licence being more restrictive for the change control, which may be of interest to ensure the integrity of QA tools).
We expect the tools to be freely usable/runnable/downloadable in any case.
Prior disclosure of Intellectual Property Rights pertaining to QA applied to W3C technology will be required, following the requirements defined in the W3C Process.
In addition to this core team, we also expect that most of the W3C technical staff acting as staff contact for a technology will end up working "part time" for QA, when their technology is up on the QA agenda. E.g. X is not in the QA team, but when the QA team starts looking closely at a Test suite for the specification he or she deal with, we expect X to free up some time/resource to coordinate with us, interface with people in the group, help us promote whatever W3C test guidelines we have come up with during WG meeting, if needed, etc.
We (the QA core team) should make our best effort to provide a clear agenda of QA related work items, with sufficient advance notice, and be flexible in our request for participation and coordination, so that the rest of the W3C staff ends up working on QA in an optimal way. That being said, the staff should realize that QA is to be considered a "natural overhead" of any WG, even if it's not written down in our process yet.
@@TBD for the working group. Likely to be similar to WAI PF, which calls for a commitment depending on the technology at stake.
Created: 2000/08/11 - Last modified 2001/02/02 by danield
Authors: Daniel Dardailler, Janet Daly, Karl Dubost