Re: TCDL Draft E

Hi,

At 10:07 12/09/2006, Shadi Abou-Zahra wrote:
>(...)
>Please find a couple of comments below for discussion:
>
>
>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?


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


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


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


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


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


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


Best regards,

Christophe



-- 
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
http://www.docarch.be/ 


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Received on Tuesday, 12 September 2006 11:14:08 UTC