Test Case Description Language

Submission to @@ Working Group @@ August 2006

This is a draft for discussion by the TSD TF only!

Editor: Christophe Strobbe (DocArch, Katholieke Universiteit Leuven).

Abstract

Test Case Description Language (TCDL) is an XML vocabulary for describing test files and evaluation scenarios for such test files, intended to be included in test suites for user interface guidelines such as Web Content Accessibility Guidelines (WCAG) 2.0.

Status of this Document

This document is a proposal from the European project BenToWeb to the Evaluation and Repair Tools (ERT) Working Group, for its considerdation and discussion of future development, if any. It has not yet been discussed, approved, or endorsed by the Working Group, even less so by W3C.

@todo04 adapt status language to where and how we submit TCDL.

Table of Contents

@@todo

Introduction

This document defines the features and syntax of Test Case Description Language (TCDL). The objective of this language is to define metadata for test cases. In addition to formal metadata and links to relevant sections in technical specifications, TCDL also supports the definition of test scenarios for the validation of test samples (for example by end users) against usability and accessibility guidelines. TCDL defines metadata for detailed descriptions of test cases, for tracking the status of test cases during the development process, for matching test cases with user profile metadata, etcetera.

TCDL can be used to support the development of suites of test samples for sets of accessibility guidelines such as the Web Content Accessibility Guidelines 2.0 (WCAG 2.0).

Definitions

technology
Markup language, programming language, style sheet, data format, or API. (WCAG2.0)
test case
An individual test that corresponds to a test purpose, which in turn maps back to the assertion(s), and finally the spec. (W3C QA Voc)
In this context: test sample or set of tet samples that correspond to a test purpose, which maps to one or more statements in one or more specifications (technical specifications on the one hand, usability or accessibility speicfications on the other).
test sample
An example or set of examples (in specific content formats) that demonstrates correct or incorrect implementation of a statement in a technical specifcation and/or a set of usability or accessibility guidelines.
test suite
A set of documents and tools providing tool developers with an objective methodology to verify the level of conformance of an implementation for a given standard. (W3C QA Voc)

How to Read this Specification

This specification reuses element and attribute types from other specifications. These element and attribute types can be recognized by the namespace prefixes that precede the names (for example, html:, dc:, xlink:). TCDL files need not use the same namespace prefixes as this specification, except where the namespace prefix is xml:, which is reserved by the XML specification (XML 1.]). References to data types defined in XML Schema Part 2: Datatypes consistenly use the xs: namespace.

This specifcation uses certain keywords as defined in RFC 2119 to indicate requirement levels; these keywords are emphasized like the following examples: must, must not, should.

The Global Structure of a TCDL File

The root element type of a TCDL file is testCaseDescription. This element type has the following attributes and namespace declarations:

Note: the namespace prefixes need not be the same as those in the above list.

Note: @@extension (attributes)

TCDL metadata are organised in five major sections, which will be explained below:

In addition, there are also several extension elements and extension points. See “Versioning XML Vocabularies” (Orchard 2003) and “Extensibility, XML Vocabularies, and XML Schema” (Orchard 2004) for more background on the extensiblity of XML vocabularies.

Below is the skeleton of a TCDL file.

<?xml version="1.0" encoding="UTF-8"?>
<testCaseDescription id="wcag20060427_sc1.1.1_l1_001"
  xml:lang="en"
  xmlns="http://bentoweb.org/refs/TCDL1.1"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:xlink="http://www.w3.org/1999/xlink"
  xmlns:html="http://www.w3.org/1999/xhtml"
  xsi:schemaLocation="http://bentoweb.org/refs/TCDL1 http://bentoweb.org/refs/schemas/tcdl1.xsd
    http://bentoweb.org/refs/TCDL1.1 http://bentoweb.org/refs/schemas/tcdl1.1.xsd
    http://purl.org/dc/elements/1.1/ http://dublincore.org/schemas/xmls/simpledc20021212.xsd
    http://www.w3.org/1999/xhtml http://www.w3.org/2004/07/xhtml/xhtml1-strict.xsd
    http://www.w3.org/1999/xlink http://bentoweb.org/refs/schemas/xlink.xsd"
  >
  <formalMetadata>
    <!-- child elements omitted -->
  </formalMetadata>
  <technology>
    <!-- child elements omitted -->
  </technology>
  <testCase complexity="atomic">
    <!-- child elements omitted -->
  </testCase>
  <rules>
    <!-- child elements omitted -->
  </rules>
  <namespaceMappings>
    <!-- child elements omitted -->
  </namespaceMappings>
</testCaseDescription>

Note: There is no normative schema for XLink; see Appendix B of the XLink specification (XLink 1.0). In the BenToWeb project, the W3C XML Schema for XLink 1.0 (METS XLink Schema, v. 2, Nov. 15, 2004), from the Metadata Encoding and Transmission Standard (METS) Official Web Site (Library of Congress) was borrowed with permission.

Formal Metadata: The formalMetadata Element Type

The formalMetadata element type contains formal or administative metadata.

This element type has the following attributes:

The formalMetadata element type also has a number of required and optional child element types, which occur in the following order:

The title Element Type

The title element type contains the title of the test case. It does not need to be unique (for example, in the test suite containing the test case) and its lenght can vary depending on the complexity of the test materials. However, the title should be sufficiently descriptive to allow a quick identification of the issue exhibited by the test case.

This element type has the following attributes:

This element type may not only contain character data but also the XHTML element types specified in XHTML-Style Inline Markup.

The dc:creator Element Type

The dc:creator element type is borrowed from the Dublin Core Metadata Element Set (DCMES 1.1) and identifies the person or organization primarily responsible for creating the test case.

This element type has no attributes.

The dc:creator element type has the data type xs:string and must therefore contain only character data.

The dc:language Element Type

The dc:language element type is borrowed from the Dublin Core Metadata Element Set (DCMES 1.1) and identifies the language of the intellectual content of the test case.

This element type has no attributes.

The dc:language element type has the data type xs:string and must therefore contain only character data. However, in TCDL the value of dc:language must be one of the language tags defined by ISO 3066. (@@todo check ISO 3066 or successor). The value must not be empty or null.

The dc:rights Element Type

The dc:rights element type is borrowed from the Dublin Core Metadata Element Set (DCMES 1.1) and describes rights held in and over the test case.

This element type has no attributes.

The dc:rights element type has the data type xs:string and must therefore contain only character data.

The date Element Type

The date element type identifies the date when the test case was created.

This element type has no attributes.

The date element type has the data type xs:date (which is inspired by ISO 8601). Example: 2004-10-01 means 1 October 2004.

The status Element Type

The status element type identifies the state of the test case during the development process of the test suite, by means of one of an enumerated list of values (for example, “draft”, “pending bugfix”, “accepted”, “rejected”).

This element type has no attributes.

The status element type has the data type xs:string, but the values should really be chose from a limited list. Defining the list of legal values is outside the scope of this specification because these values depend on the context of the test suite. For an example, see the Conformance Test Process For WCAG 2.0, which contains a description of the steps that must be performed so that a test case may be added to a test suite for WCAG 2.0.

The version Element Type

The version element type contains an identifier that allows one to distinguish between different revisions of a test case.

This element type has no attributes.

The version element type has the data type xs:string.

The source Element Type

The source element type is used to document the source of a borrowed test case and related information: the name and URL of the original test suite, the URL of the original test file, its creator, whether the file was copied literally or with changes, and rights held in and over the original test case.

This element type has the following attributes:

The source element type can only contain other element types in the following order:

The testSuite Element Type

@@todo

The sourceFile Element Type

@@todo

The dc:rights Element Type

@@todo

The comment Element Type

@@todo

The dc:contributor Element Type

The dc:contributor element type identifies the person or organization responsible for making contributions to the content of the test case.

This element type has no attributes.

The dc:contributor element type has the data type xs:string.

Technologies: The technologies Element Type

The technologies element type contains the followiing information about the technologies used in a test case:

This element type has the following attributes:

The technologies element type contains one or more instances of the technicalSpec element type.

The technicalSpec Element Type

The technicalSpec element type identifies the file format (proprietary, W3C recommendation or other type of technical specification) of the test case. There is one technicalSpec element for each file format used by the test case.

This element type has the following attributes:

The xlink:href attribute type contains the URL of the technical specification of the file format. @@data type

The baseline attribute type specifies whether something is inside or outside the baseline assumed by the test case. The value 'included' means that something is inside the baseline, 'excluded' means outside the baseline. (For information about baselines in WCAG 2.0, see Technology assumptions and the "baseline" in Web Content Accessibility Guidelines 2.0 (W3C Working Draft 27 April 2006) and About Baselines and WCAG 2.0.) [@@References]

The technicalSpec element type can contain two other element types:

The specName Element Type

The specName element type contains the name of the technology, more specifically the title of the technical specification that defines the technology. This element type may not only contain character data but also the XHTML element types specified in XHTML-Style Inline Markup.

The testElements Element Type

The testElements element type contains a description of the elements or features used by the test case. This element can be omitted for binary formats (PDF, Flash, …). This element type has no attributes. It contains at least one instance of the testElement element type.

The testElement element type contains a description of a specific element or feature. There is one testElement for each feature. For CSS, the name of the rule, selector, property, property value, … can be provided. For proprietary elements and attributes (Microsoft's bgsound, Netscape's embed, etcetera), a link to the company's documentation can be provided.

The testElement element type has an optional baseline attribute. It also contains one instance of the elementName element type, followed by one instance of either the specReference element type or the specQuote element type.

The elementName element type identifies the name of the element or feature. This element type has the following attribute types:

The localname attribute type identifies the name of the feature. If the feature is an element or attribute from an XML vocabulary, localname contains the unqualified name.

The namespace attribute type identifies the namespace URI of the feature, if relevant. This attribute type must not be used if the technology defining the feature is not an XML vocabulary.

@@data type of elementName element type undefined?

The specReference element type contains the title of the relevant section in the specification. Use the title provided by the specification wherever possible; otherwise provide a succinct and meaningful title for the relevant section in the specification.

This element type has the following attribute types:

The xlink:href attribute type contains the URL of the relevant section in the technical specification.

The specReference element type may not only contain character data but also the XHTML element types specified in XHTML-Style Inline Markup.

The specQuote element type contains a quote from the relevant section of the specification. specQuote can be used if it is not possible to provide an exact pointer to the relevant section in the specification (with specReference).

This element type has the following attribute types:

The specQuote element type may not only contain character data but also the XHTML element types specified in XHTML-Style Inline Markup.

Test Case: The testCase Element Type

The testCase element type describes what is necessary for the evaluation of the test case.

This element type has only one attribute type, complexity, with the values atomic or complex. A test case is atomic if it applies to only one checkpoint (WCAG 1.0) or success criterion (WCAG 2.0), or complex if it applies to multiple checkpoints or success criteria. [@@more general formulation?]

The testCase element type can contain five other element types:

The description Element Type

The description element type contains a summary of the test materials and how they are to be used in the test case. The description indicates to the accessibility expert/scenario author what to expect and what will happen when a user interacts with the test materials. The description of the behaviour is especially important for test materials with interactive components such as forms.

@@attributes: i18n

@@content model: XHTML-style inline markup.

The purpose Element Type

The purpose element type contains a description of the intention of the test materials. The purpose contains an explanation of the expected evaluation result in regard to the relevant rules, checkpoints or success criteria. [@@reword:] It does not need to repeat the rule or success criterion. (Strictly speaking, this goes beyond the Purpose in W3C Working Group Note on Test Metadata.)

@@attributes: i18n

@@content model: XHTML-style paragraphs.

The preconditions Element Type

The preconditions element type contains conditions that must be met before this test is executed. See Preconditions in W3C Working Group Note on Test Metadata.

@@content model: ##any (for extensiblity).

The requiredTests Element Type

The requiredTests element type describes

(In Bentoweb, each scenario has a mandatory identifier that is unique within the test case description. This identifier is necessary to map end user feedback to the scenarios.)

@@todo add detailed element type descriptions.

The files Element Type

The files element type contains information about each of the test files that are relevant to the rule or success criterion:

Supporting files such as included images, external style sheets and dummy pages to which forms are submitted (if only the form is relevant to the test) etcetera, need not be documented. (@@add: only "Web units".)

Rules: The Element Types rules and rule

The rules element type contains the “rules” that are tested by a test case. In BenToWeb, rules are generally WCAG 2.0 success criteria, but it is also possible to reference other sets of “rules”:

The rules do not provide a direct reference to the relevant online source because it may not always be possible to reference “rules” directly (for example, because they are not available in HTML). The rules reference a rule ID in a “Rulesets XML” file (@@defined elsewhere), which in turn references the relevant rule in an online source.

For each rule listed in this section, the following information can be provided:

Namespace Mappings: The Element Types namespaceMappings and namespace

This optional section is important for test cases based on test files that use XML-based technologies. The technology features (see the section on Technologies above) used in a test case exist in an XML namespace1 and should be referenceable with XPath. The normal mechanism for mapping namespaces to URIs by declaring them with xmlns:prefix= "namespaceURI" cannot be used for this, because it is necessary to be able to define empty prefixes and to extract the namespace mappings with a common XML API.

Other Content Models and Data Types

This section describes content models and data types that are used by several element types in TCDL.

XHTML-Style Inline Markup

This content model is a mixture of character data and the following XHTML elements:

The XHTML 1.0 specification allows that the above element types contain other element types. However, in TCDL the above element types must not contain element types other than those in the above list and the a element type (for links). Note that the schema for TCDL does not enforce this constraint.

XHTML-Style Paragraphs

This content model is a sequence of one or more p elements. The content model of these p elements is the XHTML-style inline markup described above.

The Attribute Types xml:lang and hrefLang

@@todo xml:lang

The hrefLang attribute type has the data type xs:language. @@todo see http://www.w3.org/TR/1999/REC-html401-19991224/struct/links.html#adef-hreflang.

The dir Attribute Type

The only values allowed for this attribute type are ltr (for left-to-right text) and rtl (for right-to-left text). When the attribute is not used, the text direction is left to right, unless another text direction is inherited from an ancestor element.

Extensibility of TCDL

@@discuss the Extension element type and the etensibility points.

Appendix A: W3C XML Schema

@@todo add XML Schema.

Appendix B: Relation with Other W3C Technical Documents and Submissions

Test Case Description Language 1.0 – Submission to QA Working Group 12 October 2003

On 12 October 2003, the Quality Assurance Working Group (QA WG) published the submission Test Case Description Language 1.0. Many sections of this document are unfinished; according to a message of Lofton Henderson to the QA WG mailing list, this version was going to be superseded.

@@todo describe diferences between the two TCDLs.

Test Metadata – W3C Working Group Note 14 September 2005

On 14 September 2005, the Quality Assurance Working Group (QA WG) published a Working Group Note on Test Metadata. (See also Testcase Metadata, draft, 9 September 2005.)

The W3C Working Group Note “Test Metadata” (14 September 2005) suggests fourteen metadata elements for test suites. The table below shows how these metadata elements map to TCDL elements. (In this table, TCDL elements are identified by means of XPath expressions without a namespace prefix and with the root element — testCaseDescription — omitted, except for the attributes of that element.)

Mapping of W3C Test Metadata to TCDL
W3C Metadata TCDL Comment
Identifier testCaseDescription/@id
Title formalMetadata/title In TCDL, titles are not necessarily unique; they don't duplicate the identifier.
Purpose testCase/purpose
Description testCase/description In TCDL, the description should help the reviewer understand how the test materials are constructed and the behaviour when a user interacts with it.
Status formalMetadata/status
SpecRef rules/rule
and
technology/technicalSpec		 In TCDL, two types of specifications need to be referenced: the accessibility guidelines (“rules”) and the specifications of the technologies in the test.
Preconditions testCase/preconditions Not used in BenToWeb, because test cases map directly to WCAG success criteria instead of tests.
Inputs testCase/files/file/httpRequest Only for the special case where it is necessary to (re)create a specific HTTP request.
ExpectedResults rules/rule/locations/@exptectedResult
and
rules/rule/functionalOutcome
Version formalMetadata/version It may be possible to rely on a version control system instead?
Contributor formalMetadata/dc:conributor
Rights formalMetadata/dc:rights
and
formalMetadata/source/dc:rights		 TCDL can document rights related to a test case and rights related to borrowed materials.
Grouping - (Because TCDL describes only single test cases, grouping should happen at a higher level.)
SeeAlso technology/recommendation
(and
rules/rule/techComment)

Appendix C: References

Conformance Test Process For WCAG 2.0
Chris Ridpath, Jenae Andershonis, eds. Conformance Test Process For WCAG 2.0. W3C Working Draft 2005-02-23.
DCMES 1.1
Dublin Core Metadata Element Set, Version 1.1: Reference Description. DCMI Recommendation 20 December 2004.
ISO 3066
@@
ISO 8601
ISO (International Organization for Standardization). Representations of dates and times, 1988-06-15.
Orchard 2003
David Orchard. Versioning XML Vocabularies. XML.com, 3 December 2003.
Orchard 2004
David Orchard. Extensibility, XML Vocabularies, and XML Schema. XML.com, 27 October 2004.
RFC 2119
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. IETF. Request for Comments 2119. BCP 14. March 1997.
W3C QA Voc
Quality Assurance glossary. W3C Quality Assurance Activity.
WCAG 2.0
Ben Caldwell, Wendy Chisholm, John Slatin, and Gregg Vanderheiden, eds. Web Content Accessibility Guidelines 2.0. W3C Last Call Working Draft 27 April 2006.
XLink 1.0
Steve DeRose, Eve Maler, David Orchard, eds. XML Linking Language (XLink) Version 1.0. W3C Recommendation 27 June 2001.
XML 1.0
Tim Bray, Jean Paoli, C. M. Sperber-McQueen, Eve Maler, François Yergeau, eds. Extensible Markup Language (XML) 1.0 (Third Edition). W3C Recommendation 04 February 2004.
XML Schema Part 2: Datatypes
Paul V. Biron, Ashok Malhotra, eds. XML Schema Part 2: Datatypes Second Edition. W3C Recommendation 28 October 2004.

Appendix D: Acknowledgements

This work has been undertaken in the framework of the project BenToWeb — IST-2-004275-STP — funded by the IST Programme of the European Commission.