Re: TCDL Draft E (second response)

Hi,

Christophe Strobbe wrote:
>> A. DC elements are frequently used, why did you create "date" and
>> "description" attributes instead adopting "dc:date" and
>> "dc:description"?
> 
> I have added notes about the limiting data types of dc:date and
> dc:description (in both cases xs:string) to the spec.

I think this is a better approach.


>> 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.
> 
> How about reusing or adapting the list from the Conformance Test
> Process For WCAG 2.0
> (http://www.w3.org/WAI/GL/WCAG20/tests/ctprocess.html)?
> Chris, do you have any objections?
> The list of values is
> - unconfirmed,
> - new,
> - assigned,
> - pending,
> - accepted,
> - rejected,
> - holding.
> For explanations, see the URL above.

I agree with this proposal, the list seems complete.


>> C. In "technologies" "xlink:href" is optional in the attached example
>> but required in the spec draft, what's the intended value?
> 
> Thanks for catching this. xlink:href is meant to be optional except on
> sourceFile (which we are probably dropping because it is part of
> source). I have corrected the spec.
> Would it be necessary to add guidance on what to put in xlink:href?

Yes please, even if it is quite clear that it should be the link to the formal specification.


>> D. If we reference browser vendor documents as "technologies", should we
>> create a test case for each browser vendor (i.e Javascript)?
> 
> I thought 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.
> Any comments or suggestions?

This is one of the things that is convincing me to keep the techComment element (see the other thread of comments).


>> 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?
> 
> The problem with defining "baseline" on the level of technologies only
> is that it is a simple binary representation that does
> not do justice to the reality of incomplete implementations by
> user agents. Some websites that put HTML 4.01 in their baseline will
> assume that every feature is supported, while others will assume that
> object, link, longdesc, etc are not adequately supported by the user
> agents of a significant percentage of their visitors. [These are not
> the best examples but I hopeh they clarify my point.] This means that
> some websites will use fall-back techniques such as 'embed', while others
> will not.
> That's why it is possible to say that technology X is in the baseline
> of a test case but element Y is not.

Is this definition of a "baseline with exceptions" really inline with WCAG 2.0?


> (I also wonder if "baseline" can handle modules in modularized specs
> such as XHTML 1.1.)
> Perhaps I should draw part of an earlier explanation about baselines
> (http://lists.w3.org/Archives/Public/public-wai-ert-tsdtf/2006Aug/0024.html) 
> 
> into the spec.

We need more discussion about this model, I am not sure I understand the whole concept.


>> 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.
> 
> We didn't get this far in the call.
> In 'testCase', 'description', 'purpose' and 'files' should stay, in
> my opinion. 'requiredTests' can be removed if the rest of the task force
> thinks it should be removed. Any comments?

I vote for removing it because I don't see a use case for it in the context of this Task Force. I am happy to hear otherwise...


Regards,
  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 Wednesday, 13 September 2006 20:42:29 UTC