Re: TCDL Draft F

Hi Christophe,

Thanks for working on this. Please find some comments below:


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.


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


> * '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!


> * 'requiredTests' will not be used [1];

What about "expertGuidance"? How does this relate to "requiredTests" and/or "techComment"?


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


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

A side question, what is the "id" property and how is it used?


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

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.


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

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?

Finally, we will now need to create WCAG 2.0 "rulesets" metadata and use it in the test metadata, right?


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


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


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

Received on Tuesday, 19 September 2006 08:52:39 UTC