W3C home > Mailing lists > Public > public-wai-ert-tsdtf@w3.org > September 2006

Re: TCDL Draft F

From: Christophe Strobbe <christophe.strobbe@esat.kuleuven.be>
Date: Wed, 20 Sep 2006 17:07:59 +0200
Message-Id: <6.0.0.22.2.20060920165309.03200448@mailserv.esat.kuleuven.be>
To: TSDTF <public-wai-ert-tsdtf@w3.org>

Hi Shadi, All,

At 20:34 19/09/2006, Shadi Abou-Zahra wrote:
>>>(...)
>>Also for dc:description, the data type is xs:string in 
>>http://dublincore.org/schemas/xmls/simpledc20021212.xsd.
>>To solve this "problem" with 'date' and 'description', we should
>>* either create our own version of the Dublin Core XML Schema and 
>>substitue the data types we want;
>>* or use the newer XML Schema 
>>(http://dublincore.org/schemas/xmls/qdc/2006/01/06/dc.xsd) - which I 
>>discovered only today - and derive our own data types from the abstract 
>>data type in that schema.
>
>I was actually not aware of this change in the DC schema, and the fact 
>that their XML schema seems significantly different from the RDF one. I 
>strongly recommend the second option but am not sure how that affects 
>compatibility with the BenToWeb TCDL.

We would need XSLT to transform BenToWeb TCDL 1.1 files into TCDL 2.0 files 
anyway.
If dc:date and dc:description in TCDL 2.0 use the same content model or 
data type as date and description (respectively) in TCDL 1.1, there should 
be no problem.

>>>What about "expertGuidance"? How does this relate to "requiredTests" 
>>>and/or "techComment"?
>>Does the task force want to drop 'expertGuidance'?
>>'requiredTests' are only for end-user evaluation. 'expertGuidance' is 
>>guidance for reviewers evaluating the test case (in BenToWeb, it is meant 
>>to explain to external users of the test suite how a test can or should 
>>be evaluated).
>
>So is the information in the "expertGuidance" an extension to the "test 
>procedure" in the Technique?

Yes, assuming that there is actually a technique to map to.


>>>>* the 'rule' element now has an optional 'techniques' element that 
>>>>enables us to point of WCAG 2.0 techniques and/or failures;
>>>
>>>Hmmm. I agree that this should be optional for a generic test case 
>>>description markup. However, in the context of this TF, there should 
>>>always be at least 1 WCAG 2.0 Technique that a test sample maps to. Agreed?
>>Do we want to constrain the language so that 'techniques' is mandatory, 
>>so that we can't create test case for which there is no technique that we 
>>can reference? (I assumed we didn't.)
>
>I can live with a "soft constraint" as well: we don't need to make this 
>constraint in the schema but it should be clear to us that our mission is 
>to develop test samples for existing techniques. I guess this constraint 
>will follow from the internal review process for the test samples anyway...

OK, so I leave 'techniques' as an optional element and add a note about 
your comment to the spec.


>>>A side question, what is the "id" property and how is it used?
>>If you mean "id" on "rule", that is explained in "The rule Element Type", 
>>with two examples in "Using rules: Examples". Does this require more guidance?
>
>Not for me, I finally get it.

OK, thanks.

>(...)
>
>>>Finally, we will now need to create WCAG 2.0 "rulesets" metadata and use 
>>>it in the test metadata, right?
>>Or reuse BenToWeb's rulesets.xml...
>
>Can you guarantee that it will not change? All the metadata generated by 
>this group will have a dependency on the rulesets.xml, changes to it could 
>have a huge impact...

... both on the TSD TF and BenToWeb. None of the rules that are currently 
in rulesets.xml will be removed or changed, only new versions of WCAG 2.0 
(or other guideline documents) will be added. Current references to 
rulesets.xml must remain valid.
Is that sufficient as a guarantee?

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 Wednesday, 20 September 2006 15:08:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:33 GMT