Re: TCDL Draft E (and some updates)

Hi Shadi, All,

At 13:48 12/09/2006, Shadi Abou-Zahra wrote:

>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.

I have added a note to the spec saying that we will use constants in 
dc:rights and dc:creator; I'll add those constants as soon as you have them.

>>>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.

I have updated the spec to our resolution (about using $version for CVS 
numbering) during the call.

>>>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.

I have updated the spec to say that we're not using these element types.

>>>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.)

>>>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?

>>>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)?

OK, I'll describe this in a separate 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.

I hope I didn't cause a misunderstanding. The location element does not 
enable you to point to procedures.

(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.)

>>An using test cases as preconditions also introduces the maintenance 
>>headache caused by test cases being dependent on other test cases...
>>>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...

We await the ERT WG's decision on this.
I still need look into EARL location pointers.

>>>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 

I have added to the spec that rules have an AND relationship. This enables 
the creation of more complex test cases. So 'rule' does not address reuse 
of test cases.

>>>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?

Best regards,


Christophe Strobbe
K.U.Leuven - Departement of Electrical Engineering - Research Group on 
Document Architectures
Kasteelpark Arenberg 10 - 3001 Leuven-Heverlee - BELGIUM
tel: +32 16 32 85 51 


Received on Tuesday, 12 September 2006 17:32:20 UTC