RE: TCDL Draft E

Hi Carlos, All,

Some quick responses below.

At 13:08 12/09/2006, Carlos Iglesias wrote:
>Another couple of comments for further discussion (apologies for the
>late sending):
>
>A. DC elements are frequently used, why did you create "date" and
>"description" attributes instead adopting "dc:date" and
>"dc:description"?

Because of the data types: we wanted real dates instead of strings,
and markup inside the descriptions instead of just character data.


>B. in "formalMetadata" "status" is intended to provide a value from an
>enumerated list, we should consider providing also a "pointer" to the
>"allowable values" or just provide a list of them for our specific use
>case.

We should create our own list when we start using TCDL.
The list used in BenToWeb is probably not appropriate for the TSD TF.


>C. In "technologies" "xlink:href" is optional in the attached example
>but required in the spec draft, what's the intended value?

I'll recheck that and respond later.


>D. If we reference browser vendor documents as "technologies", should we
>create a test case for each browser vendor (i.e Javascript)?

I think we'd rather avoid that. The browser vendor documents
sometimes describe features that have been widely adopted, for
example the controversial embed element, but there is no neutral
and stable spec that describes them.


>E. In "technologies", baseline attributes in "technicalSpec" and
>"testElement" are potentially in conflict, we should consider dropping
>one of both. Additionally, how are we going to manage baselines? Is
>expected that the group will create test cases for all posible
>combinations of baselines?

No, they are actually not in conflict. I'll describe that better in the
document.
The baseline attribute is meant to avoid the need to create test cases
for all possible baselines.


>F. In "testCase" I think that the expected results are important enough
>to deserve their own element, we should consider separating the
>"purpose" and the expected results (maybe "postconditions"?)

"purpose" is already a separate element.
A fuller response will follow later.


>G. In "testCase" the "requiredTests" element faces complex problems,
>like user testing or accessibility problems and disabilities matching,
>that need further work and consensus. I think it's out of the scope of
>this group because there is no common criterion (AFAIK there's no WCAG
>WG work on the subject), some of the properties could be useful during
>the development, but should not be published in the final version.

I expect we'll discuss this on the call.


>H. There is no much information about "rules" but I'm wondering whether
>relevant locations within the test file are necessary and if we need
>outcome information (pass or fail). IMO the whole test case is relevant
>or irrelevant, and if a rule is intended to pass a test case and other
>rule is intended to fail the same test case they are not compatible, so
>they need different test cases.

I expect we'll discuss this on the call.


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 12:34:10 UTC