Re: Metadata/Usage document

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