W3C

QA Framework: Process & Operational Guidelines

W3C Working Draft 25 February 2002

This version:
http://www.w3.org/TR/2002/WD-qaframe-ops-20020201/
Latest version:
http://www.w3.org/TR/qaframe-ops/
Previous version:
(N/A, this is the first published version)
Editors:
Kirill Gavrylyuk (kirillg@microsoft.com)
Dimitris Dimitriadis (dimitris@ontologicon.com)
Lofton Henderson (lofton@rockynet.com)
Lynne Rosenthal (lsr@nist.gov)
Contributors:
See Acknowledgments.

Abstract

This document defines a common Operational Framework for building conformance test materials for W3C specifications. It presents operational and procedural guidelines for groups undertaking conformance materials development. This document is one in a family of Framework documents of the Quality Assurance (QA) Activity, which includes the other existing or in-progress specifications: Introduction; Specification Guidelines; and, Test Materials Guidelines.

Status of this document

Note. This is an editors draft (2002-03-07), for QAWG telcon discussion.

This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.

This document is a W3C Working Draft (WD), made available by the W3C Quality Assurance (QA) Activity for discussion by W3C members and other interested parties. For more information about the QA Activity, please see the QA Activity statement.

This version is the first public Working Draft, and incorporates the discussions at the first QA face-to-face, plus several subsequent QA Working Group [QAWG] teleconferences, and supersedes all previous drafts. It is expected that updated WD versions of this document will be produced regularly, along with other members of the Framework documents family. Future progression of this document beyond Working Draft is possible, but has not yet been determined.

This part of the Framework document family will eventually have an accompanying "Process & Operational Examples and Techniques" (in progress). Some of the lengthier examples and "how to" text of this current guidelines document version will be moved to the "Examples and Techniques" document.

Please send comments to www-qa@w3.org, the publicly archived list of the QA Interest Group [QAIG]. Please note that any mail sent to this list will be publicly archived and available, do not send information you wouldn't want to see distributed, such as private data.

Publication of this document does not imply endorsement by the W3C, its membership or its staff. This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress".

A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR/.

Table of contents

1. Introduction
    1.1 Motivation for this Guidelines document
    1.2 Navigating through this document.
    1.3 Terminology
2. Guidelines
        G 1. Integrate Quality Assurance into Working Group activities.
        G 2. Define resources for Working Group QA activities.
        G 3. Synchronize QA activities with the milestones for WG deliverables.
        G 4. Define the QA process.
        G 5. QA Process: Plan test meterials development.
        G 6. QA Process: Plan test meterials publication.
        G 7. Plan the transfer of test materials to W3C if needed
        G 8. Plan for test materials maintenance
3. Working Group relationship to QA Activity
    3.1 Liaison and consultation.
    3.2 Active reviews.
    3.3 Adjudicate entry and exit criteria.
    3.4 QA resources supplement.
    3.5 Resolution of external QA requests
4. Conformance
5. Acknowledgments
6. References


1.Introduction

This document describes the process and operational activities for building conformance test suites and tools for W3C specifications. The primary goal is to assist the W3C Working Groups (WGs) by providing guidelines for the planning, development and deployment of conformance test materials. In this guideline, the term "conformance test materials" refers conformance test suites, validation tools, conformance checklists, and any other materials that are used to check or indicate conformance.

This document is part of a family of QA Framework documents designed to improve the quality of W3C specifications as well as their implementation by solidifying and extending current quality practices within the W3C. The QA Framework documents are:

The guidelines are intended for all Working Groups as well as developers of conformance materials for W3C specifications. Not only are the Working Groups the consumer of these guidelines, they are also key contributors. The guidelines capture the experiences, good practices, activities, and lessons learned of the Working Groups and present them in a comprehensive, cohesive set of documents for all to use and benefit from. The objective is to reuse what works rather than reinvent and to foster consistency across the various Working Group quality activities and deliverables.

1.1Motivation for this Guidelines document

As the complexity of W3C specifications and their interdependencies increases, quality assurance becomes even more important to ensuring their acceptance and deployment in the market. There has been a growing awareness and interest in conformance and quality. In approving and initiating the QA Activity, W3C has endorsed the principle that, in order for W3C Web standards to achieve full interoperability and access to all, the quality of the implementation must be given as much attention as the standards' development. The principal factor for improving the quality of implementation is early availability of conformance test materials.

Although not explicitly stated, the W3C Process Document supports the development of conformance test materials.

"[...] groups may produce technical reports, review the work of other groups, develop sample code or test suites, etc." (see Process Document, section 3.)
"W3C should make every effort to maintain its Recommendations (e.g., by tracking errata, providing test bed applications, helping to create test suites, etc.)" (see Process Document, section 5.2.5, "Ongoing work".)

In an effort to meet these suggestions and address the implementation requirements of the Process Document, some Working Groups have included the development of conformance materials as part of their CR-exit and PR-entrance criteria. Examples include Scalable Vector Graphics (SVG), User Agent Accessibility Guidelines (UAAG), and Extensible Style Language - Formatting Objects (XSL-FO). This makes sense, since it is natural for test suites and implementations to develop in parallel - each is a help to the development of the other.

There is already a body of contemporary QA experience and activity amongst the Working Groups. The Matrix identifies more than a score of test suites and validators, in various states of development. Moreover, many Working Groups have already established procedures, techniques and tools for developing test materials (e.g., Document Object Model - DOM). It makes sense to capitalize on what has already been done and share that with those who are starting out and those who are already in the process of developing conformance materials.

1.2Navigating through this document.

The Guidelines in the document are organized chronologically starting with those that apply at the formation of a Working Group (e.g., charter considerations) and through a progression of guidelines leads the reader through the various process and operational activities necessary in planning, developing, deploying and maintaining conformance materials. This document is applicable to all Working Groups, including those that are being rechartered or already exist. Working Groups may already be doing some of these activities and should review the document and in so far as possible incorporate principles and guidelines into their work.

This document employs the WAI (Web Accessibility Initiative) model for representing guidelines or general principles for the development of conformance materials. See, for example, Web Content Accessibility Guidelines. Each guideline includes:

The checkpoint definitions in each guideline define the processes and operations that need to be implemented in order to accomplish the guideline. Each checkpoint definition includes:

Each checkpoint is intended to be specific enough so that someone can implement the checkpoint as well as verify that the checkpoint has been satisfied.

1.3Terminology

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" will be used as defined in RFC 2119 [RFC2119].

Unusual terms in these framework documents are defined when first used, and most generally useful QA-specific terms will eventually be in the QA Glossary [QA-GLOSSARY].

2. Guidelines

Guideline 1. Integrate Quality Assurance into Working Group activities.

In approving and initiating the QA Activity, W3C has endorsed the principle that, in order for W3C Web standards to achieve full interoperability and access to all, the quality of implementation must be given as much attention as the standards' development. The principal factor for improving the quality of implementation is early availability of conformance test materials (TM). Therefore, conformance test materials -- test suites and tools -- must be considered as Working Group deliverables the same as the standards themselves. Accordingly, they must be addressed in the Working Group charter.

Checkpoints:

Checkpoint 1.1. In Charter, determine level of commitment to QA. Plan to have at least a commitment to "QA level three". [Priority 1]

Detailed planning and specification of test materials is inappropriate in the charter, as it binds the Working Group inflexibly to test materials implementation specifics for which flexibility may be needed. There are numerous possible levels of commitment that a Working Group could make, based on anticipated Working Group resources, existence of outside efforts, and the Working Group's current stage in the process [REC-TRACK].

Based on level of testability of the specification and extent of test materials, a range of possible commitments has been identified.

Level testability of the specification extent of test materials
1. Working Group plans regular specification reviews for testability, following Specification Guidelines
2. Same as above Working Group commits that a test suite for the specification, not necessarily complete and thorough, will exist before specification becomes Recommendation.
3. In addition to regular specification reviews, a Working Group aims to have numerous normative use cases in the body of the Recommendation. Same as above.
4. Same as above. Working Group commits to establish and maintain the test cases contribution and review process and will produce and review the test suite, not necessarily complete and thourough, before the specification becomes Recommendation.
5. Same as above In addition to the commitment for the previous level, insists on a complete test suite before corresponding standard becomes Recommendation.
6. In addition to the commitments from the previous levelabove, Working Group will derive the list of testable assertions as an addendum to specification by the time it becomes Recommendation. Same as above
7. Same as above In addition to the commitment for the previous level, Working Group plans to maintain the test suite even after Specification becomes recommendation. Working Group plans to support versioning and errata in the test suite and review appeals.

This 7-point enumeration is derived from a proposal to the QA mail list, after the 4/2001 QA Workshop.

The further down the scale (i.e., the higher the number) that the Working Group commits, the better it is for achieving W3C's ultimate goals of interoperability and accessibility.

Checkpoint 1.2. In Charter, identify QA deliverables, expected milestones [Priority 2]

Among QA deliverables, a Working Group may produce a set of normative usecases, produce or acquire test suite, validators, harnesses.

The W3C Process document requires for Charters, that deliverables be identified with milestones. It is vital that the milestones for QA deliverables are synchronized and even serve as criteria for WG technical deliverables (specifications).

Checkpoint 1.3. In Charter, identify QA criteria for WG deliverables milestones. [Priority 2]

A de facto convention of "CR-exit" seems to be a common process goal amongst a number the existing test suite efforts (e.g., SVG), UAAG), ...) This makes sense, as it is natural for test suites and implementations to develop in parallel -- each is a help to the development of the other. And, the Process Document does address implementation requirement:

"Advancement of a technical report to Candidate Recommendation is an explicit call for implementation experience to those outside of the related Working Groups or the W3C itself." (see Process Document, section 5.2, about "Candidate Recommendation".)
"Preferably, the Working Group should be able to demonstrate two interoperable implementations of each feature." (see Process Document, section 5.2.4, about "Entrance Criteria".)

Guideline 2. Define resources for Working Group QA activities.

Checkpoint 2.1. In Charter, address where and how conformance test materials will be produced. [Priority 1]

There are several possibilities for producing conformance test materials:

There are good reasons why external parties should have a strong participation during the building of the materials. But even if the test suite is being developed outside of W3C, the Working Group needs to ensure it is completed according to the level to which the Working Group committed in its charter.

Checkpoint 2.2. In charter, address QA staffing commitments. [Priority 2]

There will be at least some staffing required from the Working Group, for any of the acceptable options presented so far. Depending upon the general intent and plan, and how the test suite will be built, the commitment can range from minimal to significant. See "Examples & Techniques".

Guideline 3. Synchronize QA activities with the milestones for WG deliverables.

There are several strong benefits from starting synchronizing of specification and test materials developments as early as possible:

Checkpoints:

Checkpoint 3.1. Align intermediate milestones for QA deliverables with WG deliverables milestones [Priority 2]

These milestones can be naturally bound to Working Draft and/or Candidate Recommendation publications.

Checkpoint 3.2. Synchronize publication of QA deliverables and specification's drafts. [Priority 2]

Checkpoint 3.3. Support specification versioning/errata in the QA deliverables. [Priority 3]

If a Working Group plans to maintain the test suite after the specification becomes recommendation, it has to allow versioning/errata in the structure of the test materials allow to enable verification of compliance with different versions of the specification.

Guideline 4. Define the QA process.

A Working Group QA encompasses how the QA-related processes are set up within the Working Group. Documented examples of the QA Process can be found at DOM TS process, XML Schema TS process, XML Protocol TS process, etc. Naturally, in order to define QA Process within a given Working Group, the goals and scope of the QA activities must be well-defined.

Checkpoints:

Checkpoint 4.1. Define the goals and scope of QA development [Priority 1]

Common frameworks for W3C QA activities are obviously shaped by the high-level goals for development and deployment of test materials. Before further developing the framework guidelines, it is useful to state some of these high-level goals.

The over-arching goal is stated in the QA Activity Statement:

Specific goals of test materials development include:

The goals of QA work within Working Group do not encompass:

While certification may have a positive quality assurance role in standards-based Web environments, W3C does not presently intend to initiate or offer any certification services.

Checkpoint 4.2. Produce the QA Process document. [Priority 1]

Process document describes in details what does Working plans to do for QA and how it does it.

Checkpoint 4.3. Appoint QA moderator and QA taskforce. [Priority 2]

Before starting test materials development, a Working Group has to appoint several key participants for its QA process.

The role of test moderator is to manage various QA processes. Depending on the plan for the origin of the test suite a Working Group can

When a test suite is developed outside of the Working Group, a moderator often already exists in the external group that is the source of the test suite. It is recommended to invite the moderator to become a Working Group member, since he/she needs access to all Working Group materials and resources. See also section on transferring test suite from outside W3C.

Dependent on the level of involvelement of a Working Group in the test materials development, a Working Group may need to appoint QA task force in addition to the test moderator. Such a task force can take responsibility for a QA framework development, test materials development, review of contributions, maintenance. See below for details on each of these activities.

Checkpoint 4.4. In QA Process document, define means for QA-related communication. [Priority 2]

Working Group needs to choose mailing list to send all comments and announcements to.

Checkpoint 4.5. In QA Process document, specify the framework for test materials development. [Priority 2]

The QA framework describes how to develop, document and use the tests.

Checkpoint 4.6. Specify a policy for branding materials if applicable. [Priority 3]

Certification aside, some W3C activities support "branding" -- use of a conformance icon to indicate some level of standard compliance. Examples: HTML validation, CSS validation, WCAG compliance. While these content branding schemes are relatively non-controversial, there are nevertheless some serious issues which should be addressed -- particularly in the contexts of user-agent and API conformance -- before any branding-related goals are articulated.

Guideline 5. QA Process: Plan test meterials development.

As we described earlier, a Working Group may be involved in test materials development at different levels. Nevertheless at any level a Working Group needs to have clear understanding of what test framework it will use and how to insure the quality and usability of the test materials themselves.

Checkpoints:

Checkpoint 5.1. Review the Test Materials Guidelines. [Priority 2]

Taking into account the nature of the future standard (Recommendation), before starting test suite development, the test suite implementer (Working Group or 3rd party) should look at Test Materials Guidelines and decide what approach to take for test materials organization, test criteria, etc.

Checkpoint 5.2. In the test framework, ensure test materials are documented and reusable by accredited third parties for testing purposes. [Priority 2]

While W3C does not have any plans to offer any certification services, developed test materials can be used by external parties including certification services. Factors of rigor, objectivity, and defensibility are key determinants of any test materials.

Checkpoint 5.3. In QA Process document, define a contribution process. [Priority 2]

The process document must describe where to submit test materials and whom to notify (e.g., moderator) of a submission. The contribution process SHOULD describe the format of contributed material, it may contain validation harness, utilities that facilitates tests creation, templates, etc.

Checkpoint 5.4. In QA Process document, define the licenses applicable to submitted test materials. [Priority 2]

A Working Group needs to publish a license agreement under which vendors and other external parties may submit test materials. Examples of such license agreements may be found at [@@link.....]. Contributers may have to negotiate license agreement for their specific needs.

Checkpoint 5.5. In the QA Process document, define review procedures for submitted test materials. [Priority 2]

The following example meets the review requirements:

  1. Each contribution should be reviewed for its eligibility by at least one vendor other than the submitter. Any vendor involved in the creation of the Working Group test collection other than the submitter may review contributed tests.
  2. Eligibility of tests should be judged by:
  3. After review, results should be sent back to the submitter for feedback.
  4. In case of disagreement, a request for clarification should go to Working Group. Tests in question should be left out of the test suite until the W3C Working Group clarifies the issue.
  5. Only those tests that are agreed to be correct by reviewers and the submitter, or that are approved by W3C Working Group clarification, should be published.

Guideline 6. QA Process: Plan test meterials publication.

Once the test suite development started, a Working Group needs to publish the test suite drafts.

Checkpoints

Checkpoint 6.1. Ensure a secure and reliable repository location for future test materials. [Priority 2]

This doesn't necessarily mean that test suite/tools should physically reside in the W3C, although that is a recommended way of meeting the checkpoint, because:

  1. At the point that test materials become operationally deployed, then challenges to the correctness of both the test materials and specifications normally increase, and the Working Group is the best venue for initial processing and adjudication of such queries against both.
  2. Further to #1, it is more likely that technical report (Recommendation) errata processing and test suite maintenance can be kept synchronized if both responsibilities reside in the same body, the Working Group.
Once the materials have reached some advanced milestone of maturity and development (e.g., operationally usable), W3C needs to assure that:

If the Working Group ceases to operate, then other responsible for ongoing interpretation and maintenance (errata) of the standard should be designated to ensure continued availability of the test suite.

Checkpoint 6.2. In QA Process document, define the licenses applicable to published test materials. [Priority 2]

If test materials are produced within the W3C, the Working Group can choose either the W3C Document or the W3C Software license. If applicable, W3C Document license is recommended. For publishing test materials acquired from an external group, other licenses may be applicable (see transferring test suite).

Checkpoint 6.3. In the QA Process document, describe the way test materials will be published and point to the corresponding web page. [Priority 2]

If the test materials are to be published on the W3C site, it is recommended to locate them within the corresponding activity domain.

Checkpoint 6.4. Provide disclaimer regarding use of the test materials for compliance verification. [Priority 2]

Although tests suites may be used for compliance verification, users must be aware that:

  1. passing all of the tests does not guarantee full compliance of an implementation to the specification
  2. failing test suite means failing tests for specific feature they target

Checkpoint 6.5. In the QA Process document, describe how vendors can publish test results for their products, if applicable. [Priority 3]

It is recommended to use one of the practices for publishing test materials, described in Test Materials Guidelines. The Working Group can encourage vendors to publish results for their implementations, such publication ideally including or describing a test harness that would allow anyone to reproduce the results.

Guideline 7. Plan the transfer of test materials to W3C if needed

As stated before in the notes to the checkpoint for test materials repository, it is recommended that test materials reside in the W3C. If test development was done outside by some external entity or group (EG), and the Working Group (WG) together with EG decided to move test materials (TM) to W3C, the following checkpoints define the requirements for the Working Group.:

Checkpoints:

Checkpoint 7.1. If transfer of the test materials to W3C is planned, perform assessment of their quality. [Priority 2]

Checkpoint 7.2. If transfer of the test materials to W3C is planned, identify staff resources to meet requirements. [Priority 2]

Checkpoint 7.3. If transfer of the test materials to W3C is planned, resolve IPR questions and reach agreement with external party that produced test materials. [Priority 1]

Checkpoint 7.4. If transfer of the test materials to W3C is planned, update QA commitments in the Working Group charter if necessary. [Priority 2]

The following procedure is an example that meets these requirements.

Legend for the procedure:

EG
the external group or entity
QAWG
the QA Working Group
TM
the test materials
WG
the subject Working Group

Before the transfer, WG with the help of QAWG:

During transfer:

After transfer, initial process setup:

First W3C public release of new TM:

After the first public release, the TM enter maintenance phase which is described below.

Guideline 8. Plan for test materials maintenance

Once test materials development is initiated, its maintenance requires an equally significant amount of resources. Resources allocation is needed as prescribed by the maintenance checkpoint above.

Checkpoints:

Checkpoint 8.1. Maintain contribution and review procedures throughout test materials' and standard's entire life cycles. [Priority 3]

Checkpoint 8.2. In the Working Group's QA process document, specify a procedure for updates of the test materials to track new errata/specification versions. [Priority 2]

The following procedure is an example that meets the requirements:

Checkpoint 8.3. In the Working Group's QA process document, identify the communication channel and procedure for appeals of tests validity. [Priority 2]

The following procedure is an example that meets the requirements:

[Active issue] If there is still active work on the test suite even if the Working Group is not re-chartered to handle the work, then it is up to the Director to determine how this work should be done. Some options include:

3.Working Group relationship to QA Activity

The QA Activity anticipates different relationships to the various Working Groups. On the one hand, the QA-specific needs of the Working Groups will vary depending upon their resources and experience, as well as their stage in the Recommendation track. On the other hand, the W3C processes may evolve so that QA-specific process requirements are tied to milestones in the Recommendation track. This section describes relationships that may exist between a Working Groups and the QA Working Group, as well as procedures that the Working Group and QA Working Group should follow. It is more informative than normative, and does not contain any guidelines and checkpoints.

Potential relationships between Working Groups and the QA Activity include:

Key determinants of the Working Group/QA relationship will include level of available QA Activity resources, and the evolution of W3C policy on QA requirements.

3.1Liaison and consultation.

In an assistive role, the QA Activity provides consultation to Working Groups in the planning and building or acquiring of test materials. This should be the baseline relationship, applicable to all Working Groups. Consultation may be provided in formal and informal ways. Informal questions MAY be sent to www-qa@w3.org. In order to make assistance quick and accurate the following process is defined for formal requests:

3.2Active reviews.

A Working Group may submit its technical documents and test materials to the QA Working Group for review. The QA Working Group may also performs detailed review of the charter and specifications of the Working Group on request from the latter. The following procedure is used by the QA Working Group for the review of the materials presented by the Working Group. The QA Working Group MAY pro-actively initiate reviews, provided it has resources to do so.

3.3Adjudicate entry and exit criteria.

Although there are currently no W3C process requirements for QA-specific entry and exit criteria at milestones on the Recommendation track, Working Groups could define such for themselves. The QA Working Group may help identify those.

3.4QA resources supplement.

QA Working Group could, in some cases, provide resources for the planning and building of test materials for some Working Groups.

3.5Resolution of external QA requests

The QA Working Group may receive requests from external parties or persons to resolve QA related questions that involve one or several W3C standards. The Chair of QA Working Group assigns a task team of the QA Working Group members to coordinate and drive the question to resolution. The assigned task team:

4. Conformance

This section defines conformance of Working Group processes and operations to the requirements of this specification. The requirements of this specification are detailed in the checkpoints of the preceding "Guidelines" chapter of this specification, and apply to the Working Group QA-related documents and deliverables required by this specification.

This section defines three levels of conformance to this specification:

A Working Group conforms to the "QA Framework: Process & Operational Guidelines" at Level X (A, AA, or AAA) if the Working Group meets at least all Conformance Level X requirements.

To make an assertion about conformance to this document, specify:

Example:

"This QA processes and operations of this Working Group conform to W3C's 'QA Framework: Process & Operational Guidelines', available at http://www.w3.org/TR/2002/qaframe-ops/, Level AA."

5. Acknowledgments

The following QA Working Group and Interest Group participants have contributed significantly to the content of this document:

6. References

EXTERN-TA
QA activity email thread about third-party participation in test materials production, available at http://lists.w3.org/Archives/Public/www-qa/2001Oct/0060.html.
MATRIX
W3C-wide conformance activity survey covering all the Working Groups, "The Matrix", available at http://www.w3.org/QA/TheMatrix.
PROCESS
W3C Process Document, 19 July 2001, available at http://www.w3.org/Consortium/Process-20010719/.
TAXONOMY
QA Activity test taxonomy, a classification scheme for conformance test materials, available at http://www.w3.org/QA/Taxonomy.
QA-GLOSSARY
A comprehensive glossary of QA terms, maintained by the QA Working Group. (Initial version under construction.)
QAIG
Quality Assurance Interest Group of the W3C QA Activity, which may be found at http://www.w3.org/QA/IG/.
QAWG
Quality Assurance Working Group of the W3C QA Activity, which may be found at http://www.w3.org/QA/WG/.
DOM Working Group TS
Process document for DOM Working Group Test suite, available at http://www.w3.org/2002/01/DOMConformanceTS-Process-20020115.
REC-TRACK
Stages and milestones in the W3C Recommendation Track, per the Process Document (Process Document is available at http://www.w3.org/Consortium/Process-20010719/, see section 5.2).
RFC2119
Key words for use in RFCs to Indicate Requirement Levels, March 1997, available at http://www.ietf.org/rfc/rfc2119.txt.
SVGTEST
SVG Working Group's test suite resource page, which may be found at http://www.w3.org/Graphics/SVG/Test/.
WCAG10
Web Content Accessibility Guidelines, version 1.0, W3C Recommendation, 5 May 1999, available at http://www.w3.org/TR/WCAG10/.
WG-QA-RANGE
Email proposal by David Marston, on the QA public mail list, for range of Working Group commitment levels to conformance test materials production, available at http://lists.w3.org/Archives/Public/www-qa/2001Apr/0004.html.
XMLTEST
OASIS XML Conformance TC's XML test suite resource page, which may be found at http://www.oasis-open.org/committees/xml-conformance/.
XSLT-TEST
OASIS XML Conformance TC's XSLT/Xpath test suite resource page, which may be found at http://www.oasis-open.org/committees/xml-conformance/.
QAF-TEST
QA Framework: Test Materials Guidelines (not yet published).
QAF-SPEC
QA Framework: Specification Guidelines (not yet published).