Editor(s): Christophe Strobbe (DocArch, Katholieke Universiteit Leuven),
…
This document describes the metadata used by the Test Samples Development Task Force (TSD TF). It describes the subset of Test Case Description Language 2.0 (TCDL) 2.0 used by the task force and the way in which it is used.
This is a draft for discussion by the TSD TF only.
Note: use of Test Case Description Language (TCDL) by the Test Samples Development Task Force (TSD TF) does not imply any kind of endorsement by the World Wide Web Consortium (W3C) or any of its working groups.
formalMetadata Element Type
technologies Element Type
testCase Element
Type
rules and
rule
namespaceMappings and namespaceThis document describes the usage of certain features of Test Case Description Language 2.0 (TCDL 2.0) by the Test Samples Development Task Force. The Task Force does not use all the features from that language but only a core set that it considers relevant to its requirements.
formalMetadata Element TypeSpecification: see Formal
Metadata: The formalMetadata Element Type.
The formalMetadata element type also has a number of required
and optional child element types. The TSD
TF uses the following element types, which occur in the
following order:
title (required),dc:creator (required),dc:language (required),dc:rights (required),dc:date (required),status (required),version (required).Note: other child element types of formalMetadata, namely
dc:contributor and source (and its descendants),
are not used by the TSD TF .
title Element TypeSpecification: see The
title Element Type.
dc:creator Element TypeSpecification: see The
dc:creator Element Type.
The TSD TF uses a
constant value [@@todo add constant value], so the dc:creator
element always looks as follows:
<dc:creator>[@@constant</dc:creator>.
dc:language Element TypeSpecification: see The
dc:language Element Type.
dc:rights Element TypeSpecification: see The
dc:rights Element Type.
The TSD TF uses a
constant value [@@todo add constant value], so the dc:rights
element always looks as follows: <dc:rights>[@@constant with
pointer to license]</dc:rights>.
dc:date Element TypeSpecification: see The
dc:date Element Type.
status Element TypeSpecification: see 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.
The TSD TF use the values used in the Conformance Test Process For WCAG 2.0, namely:
version Element TypeSpecification: see The
version Element Type.
The version element type contains an identifier that allows
one to distinguish between different revisions of a test case.
The TSD TF uses
CVS numbering for test cases by inserting “$Revision$”
in the first version of a test case uploaded to CVS, so
the versioning system automatically generates the version number.
Consequently, the version element always looks as follows:
<version>$Revision: 1.3 $/version> (where 1.3 stands
for the CVS revision number).
technologies Element TypeSpecification: see Technologies:
The technologies Element Type.
technicalSpec Element TypeSpecification: see The
technicalSpec Element Type.
Note: at the time of writing [@@date], it is not entirely clear whether WCAG baselines will only contain complete technologies or also mention specific features. The issue was discussed in March, with some arguments in favour of very granular baseline information. WCAG conformance claims don't need to specify what technologies were used outside the baseline, but it seems desirable that test case metadata are more precise in this area.
specName
Element TypeSpecification: see The
specName Element Type.
testElements Element TypeSpecification: see The
testElements Element Type.
This element type allows developers to check how well a test suite covers certain features, especially accessibility features, of a technology. This could help the TSD TF to get help and/or test cases from other working groups (who often have test suites of their own). The TSD TF may decide later that storing this information requires too many resources and drop this element type.
testCase Element TypeSpecification: see Test Case: The
testCase Element Type.
The testCase element type describes what is necessary for the
evaluation of the test case. The testCase element type can
contain six other element types:
dc:description (required),purpose (required),expertGuidance (optional),preconditions (optional),files (required).Note: other child element types of testCase, namely
requiredTests (and its descendants), are not used by the
TSD TF .
dc:description Element TypeSpecification: see Test Case:
The dc:description Element Type.
purpose Element TypeSpecification: see The
purpose Element Type.
expertGuidance Element TypeSpecification: see The
expertGuidance Element Type.
preconditions Element TypeSpecification: see The
preconditions Element Type.
This element type is provided for extensibility; it can contain any
elements in any namespace other than the target namespace
(##other).
Note: the TSD TF may drop this element later if it does not turn out to be useful (comment on TCDL draft F).
files Element TypeSpecification: see The
files Element Type.
file Element
TypeSpecification: see The file
Element Type.
The file element type can only contain one element type:
httpRequest (optional).Note: the TSD
TF is interested in replacing the current
httpRequest with HTTP
Vocabulary in RDF.
httpRequest Element Type.Specification: see The
httpRequest Element Type.
rules and ruleSpecification: see Rules: The Element Types rules and rule.
rule Element TypeSpecification: see The rule
Element Type.
The rule element type contains the following element types,
which occur in the following order:
locations (required),techniques (optional),techComment (optional).Note: other child element types of rule, namely
functionalOutcome (and its descendants), are not used by the
TSD TF .
locations
Element TypeSpecification: see The
locations Element Type.
techniques Element TypeSpecification: see The
techniques Element Type.
technique
Element TypeSpecification: see The
technique Element Type.
techComment Element TypeSpecification: see The
techComment Element Type.
namespaceMappings
and namespaceSpecification: see Namespace
Mappings: The Element Types namespaceMappings and
namespace.
The TSD TF uses the following naming convention for the ID of test cases: sca.b.c_lz_nnn, where the sections separated by underscores have the following meaning:
This convention applies to the TCDL file names, the
test file names and the IDs used in the TCDL
files (id attribute on root element).
The ID for the first XHTML test case for
success criterion 1.1.1 (level 1) would look like this:
sc1.1.1_l1_001. This means that sc1.1.1_l1_001 is
the value of the id attribute of the
testCaseDescription element, that the TCDL
file would be named sc1.1.1_l1_001.xml and the
XHTML file sc1.1.1_l1_001.html.
Finally, if more than one test file is necessary for the same test case, it is possible add an additional _001, _002, etcetera to the test file names (before the file name extension).
@@todo