Re: TCDL Draft E (and some updates)

Hi,

Christophe Strobbe wrote:
>>>> 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?
> 
> That's what the Extension element type and the extension point are for. 
> This mechanism allows us to control where such elements can be added, so 
> that they are added in a controlled way instead of just anywhere (which 
> would just cause chaos, in my opinion). I have at last written the 
> section on extensibility of TCDL, where this is explained.
> 
> (Note that adding new elements and attributes to the schema can also be 
> done outside these extensibility points, and that comes obviously at the 
> price of updating all the existin files.)

It seems we are provoking a philosophical discussion. I'm happy to leave the Extension element inside for now and see where we get at. However, please include a note that parsers (and validators) should ignore additional elements or attributes that they do not know. Maybe that is already in the extensibility section, I have to check.


>>>> 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...
> 
> "testElement" and "testElements" would enable us 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). I have added a note about this to the spec.
> 
> "testElement" is not meant to refer to WCAG, however. References to 
> success criteria are meant to be in the "rules" section. Does this 
> require a clearer explanation in the spec?

Yes, on the last call we agreed to keep it in for now but closely monitor how much discussion and hence resource consumption this feature will cause. There are clear advantages but I also fear a lot more work...


> (A related issue: there are test procedures in the WCAG techniques 
> document, but the "rules" section only points to success criteria, not 
> techniques or failures. It is possible to provide links to techniques or 
> failures in other TCDL elements, e.g. techComment, because they allow 
> limited HTML markup, but there is currently no "standard" mechanism for 
> pointing to test procedures, techniques or failures. Perhaps we should 
> discuss this in a separate thread.)

Yes, I agree we should. It is clear that we need to point to the success criteria but equally well we should point to the techniques that were used to evaluate a success criteria using the test case. IMO this should not be a comment but a machine readable pointer.


>>>> 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.
> 
> I would keep techComment: it's a handy place for recording user agent 
> support notes and other technical stuff. I use it a lot in BenToWeb. If 
> we drop this element, this information would need to go into 
> 'description'. Any comments?

You convinced me. There is probably a strong case for being able to record all the nitty-gritty technical comments, stuff that may go beyond a mere description of the test case.


Thanks,
 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 Wednesday, 13 September 2006 20:29:18 UTC