Re: TCDL Draft E

H,

Christophe Strobbe wrote:
>> 1. In "formalMetadata" we should consider making dc:creator and 
>> dc:rights constant values. The creator is this Task Force (and/or the 
>> WGs), and the copyrights are W3C. It would be good to have a 
>> possibility to point to the license too!
> 
> dc:rights is wider than copyright. Would it be an appropriate place for 
> a reference to the license or do we need something else?

You are right, dc:rights may be sufficient.


>> 2. In "formalMetadata" we should consider making the version number 
>> required. I think it is important to count both the test as well as 
>> the test suite version numbers. Maybe a numbering convention like 
>> S.T.U = "Test Suite number"."Test number"."Update number" could help? 
>> For example, 1.3.14 means the Test Suite version 1, Test version 3, 
>> and Update to that test number 14.
> 
> We could make version numbering required, but in BenToWeb we manage very 
> well without it. What exactly would you use it for?

If we are not going to use it, then I think we should drop it.


>> 3. In "formalMetadata" we should consider dropping the source and 
>> dc:contributor elements because we need to be careful with "borrowing" 
>> stuff and potentially overwriting the copyrights.
> 
> OK.
> 
> 
>> 4. In "formalMetadata" we should consider dropping the Extension 
>> element unless there is a strong use case. Remember, the scope is only 
>> this Task Force, we can always add things later on as needed.
> 
> The optional Extension element gives you a way to do this without making 
> the existing files invalid...

Hmmm. How about defining that parsers are expected to ignore elements they don't know?


>> 5. In "technologies" what is the use case for the "testElement"? (It 
>> seems to me to be part of the files element in the testCase).
> 
> It allows you to specify which specific feature of a technology the test 
> case focuses on. Later on, you can easily search through the TCDL files 
> to check if you have covered certain features of a technology (e.g. 
> specific accessibility features of HTML).

Interesting. So a single Test Suite could server for both WCAG 2.0 and technology X.Y (for example HTML 4.01)?

If so, I am concerned about scope creeping for the mission of this Task Force. On the other hand, it is a neat feature to have...


>> 6. In "testCase" I am confused between the precondition and the 
>> requiredTests elements. I think the preconditions element should 
>> provide a mechanism to point to other test cases and the expected 
>> results, and the requiredTests should be dropped.
> 
> requiredTests is what we use in BenToWeb to validate a test case.

I can't get my head around to how this is done. Could you elaborate on this (maybe in a different thread)?


> As for pointing to test cases in 'preconditions': I just don't 
> understand how *test cases* can serve as preconditions for other test 
> cases; I would expect that you use *test procedures* with certain 
> outcomes as preconditions.

I was not aware that you can point to several test procedures through the location element. See below for more.


> An using test cases as preconditions also introduces the maintenance 
> headache caused by test cases being dependent on other test cases...

Agreed.


>> 7. In "testCase" we should consider leaning on the EARL location 
>> pointers to express line/column, xpath, etc.
> 
> Hm. As long as line and column numbers start at 1 instead of 0.

*LOL*! It would be indeed good to align EARL and TCDL at this stage. I don't have a preference for either way...


>> 8. In "testCase" what does it mean if one location is expected to 
>> fail, and another is expected to pass? Shouldn't there be one expected 
>> result for the test case as a whole then separate location pointers to 
>> the occurence(s) of the trigger?
> 
> Within the same 'rule' element, you can't say that one location passes 
> and that another fails because the 'locations' (notice the plural) 
> element is not repeatable.
> What you can say, however, is that a test case passes for one rule (e.g. 
> colour contrast) but fails for another one (e.g. wellformedness).
> We could make the 'rule' element non-repeatable, so test cases map to 
> one rule only.

No, I think it is good to have one test case be reusable for several test procedures!


>> 9. In "testCase" what is the functionalOutcome? Is that the expected 
>> result for the test case as a whole? What is the techComment then 
>> exactly?
> 
> functionalOutcome can be used to describe the user's experience with the 
> test sample without going into technical details such as source code, 
> whereas techComment can be used to describe the technical stuff 
> (including source code, references to specs, etcetera) that is useful to 
> developers of test cases.
> The distinction comes from BenToWeb's process where test cases are 
> developed by people with good technical knowledge (some of which can be 
> recorded in 'techComment') and are reviewed by people who do not 
> necessarily have the same technical knowledge and therefore would 
> benefit from a less technical description (e.g. in functionalOutcome).
> 
> (Strictly speaking, it is possible to drop functionalOutcome because the 
> description and purpose elements are sufficiently expressive.)

I vote for dropping it in the context of this Task Force.


Regards,
  Shadi


-- 
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, 12 September 2006 11:48:52 UTC