Re: TCDL Draft F

Hi Shadi,

At 10:51 19/09/2006, Shadi Abou-Zahra wrote:
>(...)
>Christophe Strobbe wrote:
>>* 'date' now says that it was chosen over 'dc:date' because of the data type;
>
> From the DC spec [1] it reads:
>
>"Typically, Date will be associated with the creation or availability of 
>the resource. Recommended best practice for encoding the date value is 
>defined in a profile of ISO 8601 [W3CDTF] and includes (among others) 
>dates of the form YYYY-MM-DD."
>
>[1] <http://www.dublincore.org/documents/dces/>
>
>So infact the datatype of dc:date is not xsd:string, it is left open. DC 
>only *recommend* using the W3C DTF (Date Time Format) which maps to 
>xsd:gDate. I think we should reuse dc:date and xsd:gDate values.

TCDL imports the XML Schema for Dublin Core, where the data type of dc:date 
is xs:string, not xs:gDate (at least in the schema that we've used so far: 
http://dublincore.org/schemas/xmls/simpledc20021212.xsd). See also my 
comment below on 'description'.



>>* 'technicalSpec/@xlink:href' now has 6 examples to clarify what should 
>>go in that attribute;
>>* 'specReference/@xlink:href' now has 4 examples to clarify what should 
>>go in that attribute;
>>* 'testElements' now says that we will drop it if it turns out to drain 
>>too many resources;
>>* a section on baselines has been added;
>
>OK, this is now much clearer. Just one minor comment: please reference 
>(and link) the section on baselines from the section "technicalSpec". I 
>only understood the concept (and saw an example of how to use the 
>property) after reading all the way down. Anyway, really minor for the 
>next revision.

OK, consider it done.



>>* 'description' now says it was chosen over 'dc:description' because of 
>>the data type;
>
>Again, I think DC allows you to choose a datatype pretty flexibly. I vote 
>for reusing vocabulary where possible...
>
>PS: thanks for explaining that the "purpose" goes beyond the "purpose" in 
>the techniques!

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.



>>* 'requiredTests' will not be used [1];
>
>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).



>>* 'file/@xlink:href' now has examples to clarify what should go in that 
>>attribute;
>
>Thanks, this helps a lot!
>
>
>>* in 'httpRequest' the attributes enctype and mediatype were removed 
>>(header elements could cover the same function);
>>* in 'httpRequest', the attribute 'method' (for specifying the HTTP 
>>method) was added;
>
>Johannes and CarlosV have worked on a wonderful "HTTP Vocabulary in RDF" 
>document [2] that I recommend we reuse here as well (of course as mere XML 
>elements). See the questions below on the extension model.
>
>[2] <http://www.w3.org/WAI/ER/HTTP/WD-HTTP-in-RDF-20060705>

OK, I'll look into that for the next draft.



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


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



>>* there is now a chapter on the extensibility mechanisms;
>
>I quite strongly disagree with this extension model. IMO, parsers should 
>simply ignore elements and attributes they don't know, and let the chaos 
>have its way... ;)

I don't understand why you disagree, unless you want to allow undefined 
elements and attributes *anywhere* in a TCDL file. This would require that 
I add xs:any (= any elements) before/after every defined element and that I 
add xs:anyAttribute to any element. Is that really what we want??
(In the light of this discussion, I find it somewhat hard to understand why 
some people insist on removing optional elements such as 'requiredTests'.)


>A good example is the location pointers (see more background at the end of 
>this mail): it just does not make sense to have to add the pointers in a 
>completely different part of the XML tree (in the "Extension" part) 
>instead of just extending the existing "locations" part of TCDL. Anyway, 
>we need to decide on the extension model.

I can add more extension points (with 'Extension' etc) where you think it 
would be necessary.



>>* there is now a chapter on the "Rulesets XML";
>
>ahaaaaa, now I think I understand the "id" property from above. Hmmmm, 
>this opens the question why the "techniques" element is not inside the 
>"Rulesets XML" instead of being inside TCDL. Was there a specific reason 
>for this?

Well, the techniques documents were too immature when BenToWeb started 
working on the test suites, and the success criteria are the only normative 
"rules". If you fail an SC, you fail to conform, but if you fail a 
technique, you can't make a definitive statement on conformance. So we 
never add "rules" for techniques.


>Also, knowing that you may hate me, more description and examples are 
>needed for this section. Or maybe a different document all together to 
>describe this vocabulary?

Hmm, this is a very simple language, and if we can reuse BenToWeb's 
rulesets.xml file (which will be updated with newer WCAG drafts), there is 
only one person who needs to update 'rulesets.xml' (=me).


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


>>* there is now a chapter describing the ID/naming convention for the test 
>>cases (http://www.w3.org/2006/09/05-tsdtf-minutes).
>
>Thanks for adding this.
>
>
>>Some other issues:
>>* I have assumed that we wanted to make 'version' required.
>
>My understanding is that this was a decision from the previous call. It is 
>required but also a constant value to the editor (the actual value will be 
>added by the CVS server automagically).

That was also my understanding, but the resolution in the minutes is not 
that clear.


>>* Do we want to remove 'preconditions' or is there a use case for it?
>
>I can't think of use case but can imagine it could be useful. Let's keep 
>it in for now.

OK.


>>* I have not yet added the EARL location pointers.
>
>Since the TCDL pointers are (optional) attributes, the EARL location 
>pointers would be a compatible extension. We need to think of how to do 
>this extension correctly, which goes back again to the extension model 
>that we still need to agree on.
>
>
>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 |

-- 
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, 19 September 2006 12:20:29 UTC