Editor(s): Christophe Strobbe (DocArch, Katholieke Universiteit Leuven),
…
This document describes the metadata used by the Test Samples Development Task Force (TSD TF). The TSD TF creates content samples for WCAG 2.0 Techniques. Each content sample has an associated metadata file in an XML format that is a subset of Test Case Description Language 2.0 (TCDL) 2.0. This document describes which elements and attributes of TCDL 2.0 are used by the task force and the way in which they are 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.
@@todo table or definition list with all TCDL elements/terms used by the Task Force, similar to EARL 1.0 Terms.
A metadata file consists of the following sections or elements:
formalMetadata (administrative metadata such as title,
author, date and rights),technologies (web technologies used in the test sample,
such as HTML, CSS and
JavaScript),testCase (reference to test sample),rules (reference to success criterion and
technique/failure, with pass/fail statement),namespaceMappings (for namespaces used in XPath and
XPointer expressions in the rules section).See also The Global Structure of a TCDL File.
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, so the dc:creator element always looks as
follows:
<dc:creator xsi:type="btw:dcHtmlInline">Developed
by <html:a href="http://www.w3.org/"><html:acronym title="World Wide Web Consortium">W3C</html:acronym></html:a>/<html:a href="http://www.w3.org/WAI/"><html:acronym title="Web Accessibility Initiative">WAI</html:acronym></html:a>'s<html:a href="http://www.w3.org/WAI/ER/">Evaluation and Repair Tools Working Group</html:a>
(ERT WG). We invite comments and discussion. Please
address your feedback to <html:a href="mailto:public-wai-ert-tests@w3.org">public-wai-ert-tests@w3.org</html:a>, a mailing list with a <html:a href="http://lists.w3.org/Archives/Public/public-wai-ert-tests/">public archive</html:a>.</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, so the dc:rights element always looks as
follows:
<dc:rights xsi:type="btw:dcHtmlInline"><html:a rel="Copyright" href="/Consortium/Legal/ipr-notice#Copyright">Copyright</html:a> ©
1994-2006 <html:a href="/"><html:acronym title="World
Wide Web Consortium">W3C</html:acronym></html:a><html:sup>®</html:sup> (<html:a href="http://www.csail.mit.edu/"><html:acronym
title="Massachusetts Institute of
Technology">MIT</html:acronym></html:a>, <html:a href="http://www.ercim.org/"><html:acronym title="European Research Consortium for Informatics and
Mathematics">ERCIM</html:acronym></html:a>, <html:a href="http://www.keio.ac.jp/">Keio</html:a>), All Rights
Reserved. <html:acronym title="World Wide Web
Consortium">W3C</html:acronym>
<html:a href="/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</html:a>,
<html:a href="/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</html:a>,
<html:a rel="Copyright" href="/Consortium/Legal/copyright-documents">document use</html:a> and <html:a rel="Copyright" href="/Consortium/Legal/copyright-software">software licensing</html:a> rules apply. Your interactions with this site are in accordance
with our <html:a href="/Consortium/Legal/privacy-statement#Public">public</html:a> and
<html:a href="/Consortium/Legal/privacy-statement#Members">Member</html:a> privacy
statements.</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. Note that
expertGuidance should not “interpret” the technique or
failure referenced by the test case.
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 (required),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. Each each test sample developed by
the task force must be linked to a WCAG 2.0 technique or
failure (resolution 17
October 2006).
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).
Test suites are organized by main technology: XHTML, SVG, etcetera. The names of the directories match those of the technologies (XHTML, SVG, etcetera).
Test files are stored in the directory “testfiles”; test case descriptions are stored in the directory “metadata”. Resources used by the testfiles are in separate directories. The directory structure for each of the test suites looks as follows:
@@todo
@@todo