- From: Shadi Abou-Zahra <shadi@w3.org>
- Date: Tue, 17 Oct 2006 11:11:12 +0200
- To: public-wai-ert-tsdtf@w3.org
Hi, I've uploaded this first version of the "usage document": * <http://www.w3.org/WAI/ER/tests/usingTCDL> Regards, Shadi cstrobbe wrote: > Dear task force participants, > > Please find attached a draft of the usage document (an action item I > got last week: > http://www.w3.org/2006/10/03-tsdtf-minutes.html#action02). > This document also states which parts of TCDL 2.0 are not used. > > Please let me know if this is a workable format and if you have any > issues with it. > > Best regards, > > Christophe Strobbe > > > > ------------------------------------------------------------------------ > > > Metadata Used by the Test Samples Development Task Force (TSD TF) > > Editor(s): Christophe Strobbe (DocArch <http://www.docarch.be/>, Katholieke > Universiteit Leuven), > > > Abstract > > 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 <http://bentoweb.org/refs/TCDL2.0.html> used by the task force and > the way in which it is used. > > > Status of this Document > > 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. > > > Table of Contents > > * Introduction <#chapt-intro> > * Terms and Definitions <#chapt-terms> > * The Global Structure of a TCDL File <#chapt-global> > * Formal Metadata: The |formalMetadata| Element Type <#edef-formalmetadata> > o The |title| Element Type <#edef-title> > o The |dc:creator| Element Type <#edef-dccreator> > o The |dc:language| Element Type <#edef-dclanguage> > o The |dc:rights| Element Type <#edef-dcrights> > o The |dc:date| Element Type <#edef-dcdate> > o The |status| Element Type <#edef-status> > o The |version| Element Type <#edef-version> > * Technologies: The |technologies| Element Type <#edef-technologies> > o The |technicalSpec| Element Type <#edef-technicalspec> > + The |specName| Element Type <#edef-specname> > + The |testElements| Element Type <#edef-testelements> > * Test Case: The |testCase| Element Type <#edef-testcase> > o The |dc:description| Element Type <#edef-dcdescription> > o The |purpose| Element Type <#edef-purpose> > o The |expertGuidance| Element Type <#edef-expertguidance> > o The |preconditions| Element Type <#edef-preconditions> > o The |files| Element Type <#edef-files> > * Rules: The Element Types |rules| and |rule| <#edef-rules> > o The |rule| Element Type <#edef-rule> > o Using |rules|: Examples <#rules-egs> > * Namespace Mappings: The Element Types |namespaceMappings| and |namespace| > <#edef-namespacemappings> > * Naming Conventions <#chapt-conventions> > > > Introduction > > This 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. > > > Terms and Definitions > > technology > Markup language, programming language, style sheet, data format, or API. > (Source: WCAG2.0 <#ref-wcag20>.) > test case > An individual test that corresponds to a test purpose, which in turn maps > back to the assertion(s), and finally the spec. (Source: W3C QA Voc > <#ref-w3cqavoc>.) > 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. (Source: W3C QA Voc <#ref-w3cqavoc>.) > > > The Global Structure of a TCDL File > > See The Global Structure of a TCDL File > <http://bentoweb.org/refs/TCDL2.0.html#chapt-global>. > > > Formal Metadata: The |formalMetadata| Element Type > > Specification: see Formal Metadata: The |formalMetadata| Element Type > <http://bentoweb.org/refs/TCDL2.0.html#edef-formalmetadata>. > > 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 . > > > The |title| Element Type > > Specification: see The |title| Element Type > <http://bentoweb.org/refs/TCDL2.0.html#edef-title>. > > > The |dc:creator| Element Type > > Specification: see The |dc:creator| Element Type > <http://bentoweb.org/refs/TCDL2.0.html#edef-dccreator>. > > 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>|. > > > The |dc:language| Element Type > > Specification: see The |dc:language| Element Type > <http://bentoweb.org/refs/TCDL2.0.html#edef-dclanguage>. > > > The |dc:rights| Element Type > > Specification: see The |dc:rights| Element Type > <http://bentoweb.org/refs/TCDL2.0.html#edef-dcrights>. > > 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>|. > > > The |dc:date| Element Type > > Specification: see The |dc:date| Element Type > <http://bentoweb.org/refs/TCDL2.0.html#edef-dcdate>. > > > The |status| Element Type > > Specification: see The |status| Element Type > <http://bentoweb.org/refs/TCDL2.0.html#edef-status>. > > 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 > <#ref-wcagctp>, namely: > > * unconfirmed, > * new, > * assigned, > * pending, > * accepted, > * rejected, > * holding. > > > The |version| Element Type > > Specification: see The |version| Element Type > <http://bentoweb.org/refs/TCDL2.0.html#edef-version>. > > 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: The |technologies| Element Type > > Specification: see Technologies: The |technologies| Element Type > <http://bentoweb.org/refs/TCDL2.0.html#edef-technologies>. > > > The |technicalSpec| Element Type > > Specification: see The |technicalSpec| Element Type > <http://bentoweb.org/refs/TCDL2.0.html#edef-technicalspec>. > > 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 > <http://lists.w3.org/Archives/Public/w3c-wai-gl/2006JanMar/0585.html>. 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. > > > The |specName| Element Type > > Specification: see The |specName| Element Type > <http://bentoweb.org/refs/TCDL2.0.html#edef-specname>. > > > The |testElements| Element Type > > Specification: see The |testElements| Element Type > <http://bentoweb.org/refs/TCDL2.0.html#edef-testElements>. > > 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. > > > Test Case: The |testCase| Element Type > > Specification: see Test Case: The |testCase| Element Type > <http://bentoweb.org/refs/TCDL2.0.html#edef-testcase>. > > 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 . > > > The |dc:description| Element Type > > Specification: see Test Case: The |dc:description| Element Type > <http://bentoweb.org/refs/TCDL2.0.html#edef-dcdescription>. > > > The |purpose| Element Type > > Specification: see The |purpose| Element Type > <http://bentoweb.org/refs/TCDL2.0.html#edef-purpose>. > > > The |expertGuidance| Element Type > > Specification: see The |expertGuidance| Element Type > <http://bentoweb.org/refs/TCDL2.0.html#edef-expertguidance>. > > > The |preconditions| Element Type > > Specification: see The |preconditions| Element Type > <http://bentoweb.org/refs/TCDL2.0.html#edef-preconditions>. > > 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 > <http://lists.w3.org/Archives/Public/public-wai-ert-tsdtf/2006Sep/0022.html>). > > > The |files| Element Type > > Specification: see The |files| Element Type > <http://bentoweb.org/refs/TCDL2.0.html#edef-files>. > > > The |file| Element Type > > Specification: see The |file| Element Type > <http://bentoweb.org/refs/TCDL2.0.html#edef-file>. > > 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 <#ref-httprdf>. > > > The |httpRequest| Element Type. > > Specification: see The |httpRequest| Element Type > <http://bentoweb.org/refs/TCDL2.0.html#edef-httprequest>. > > > Rules: The Element Types |rules| and |rule| > > Specification: see Rules: The Element Types |rules| and |rule| > <http://bentoweb.org/refs/TCDL2.0.html#edef-rules>. > > > The |rule| Element Type > > Specification: see The |rule| Element Type > <http://bentoweb.org/refs/TCDL2.0.html#edef-rule>. > > 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 . > > > The |locations| Element Type > > Specification: see The |locations| Element Type > <http://bentoweb.org/refs/TCDL2.0.html#edef-locations>. > > > The |techniques| Element Type > > Specification: see The |techniques| Element Type > <http://bentoweb.org/refs/TCDL2.0.html#edef-techniques>. > > > The |technique| Element Type > > Specification: see The |technique| Element Type > <http://bentoweb.org/refs/TCDL2.0.html#edef-technique>. > > > The |techComment| Element Type > > Specification: see The |techComment| Element Type > <http://bentoweb.org/refs/TCDL2.0.html#edef-techcomment>. > > > Namespace Mappings: The Element Types |namespaceMappings| and |namespace| > > Specification: see Namespace Mappings: The Element Types |namespaceMappings| and > |namespace| <http://bentoweb.org/refs/TCDL2.0.html#edef-namespacemappings>. > > > Naming Conventions > > 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: > > sca.b.c > the number of the success criterion, > lz > the level of the success criterion, > nnn > the number of the test case (numbering starts from 001 for each success > criterion). > > 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). > > > Appendix A: References > > > Appendix B: Acknowledgements > > @@todo > -- Shadi Abou-Zahra Web Accessibility Specialist for Europe | Chair & Staff Contact for the Evaluation and Repair Tools WG | World Wide Web Consortium (W3C) http://www.w3.org/ | Web Accessibility Initiative (WAI), http://www.w3.org/WAI/ | WAI-TIES Project, http://www.w3.org/WAI/TIES/ | Evaluation and Repair Tools WG, http://www.w3.org/WAI/ER/ | 2004, Route des Lucioles - 06560, Sophia-Antipolis - France | Voice: +33(0)4 92 38 50 64 Fax: +33(0)4 92 38 78 22 |
Received on Tuesday, 17 October 2006 09:11:32 UTC