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

Re: New TCDL draft - Re: TSD TF: Agenda for 22 August 2006

From: Christophe Strobbe <christophe.strobbe@esat.kuleuven.be>
Date: Mon, 28 Aug 2006 16:30:16 +0200
Message-Id: <6.0.0.22.2.20060828154534.02f76948@mailserv.esat.kuleuven.be>
To: public-wai-ert-tsdtf@w3.org

Hi Tim,

Thanks for your comments.

At 15:34 28/08/2006, Tim Boland wrote:
>Thanks for the good work.
>
>For the "version" element type (Section 8.7), what level of "revision" is
>necessary to consistute a new "version" (NOTE: At least for a specification,
>the W3C QA Handbook [1] mentions a new version as "referring to a significant
>functional change and enhancement".

This is something I have left undefined (we don't use it in BenToWeb).
I think that the context should define what constitutes "a significant
functional change and enhancement", i.e. in our case the TSD TF, rather
than the language.
(If we only consider our own use case for TCDL, we could put that into the
spec.)
The WG Note on Test Metadata contains the following note about "version" [2]:
<quote>
ISSUE: It is unclear whether it is necessary to apply version numbers to 
individual tests. More common practice is to version the entire test suite. 
Ideally tests will not need to be revised as the specification evolves. 
However, this is sometimes necessary, and at a minimum each Working Group 
should define SpecRef and possibly other metadata such as Grouping elements 
to indicate which versions of the specification an individual test supports.
</quote>
(In TCDL, we have two types of "SpecRef":
- "technicalSpec" and its child elements;
- "rules".
In each case, URLs should refer to dated versions of specifications, so
that it is always clear which version is referenced.)


>For the "technologies" element type (Section 9), are there ever 
>"technologies"
>that are not/cannot be defined by "a formal specification or recommendation"?
>Is there a definition of "technologies" assumed for this element type?

The definition of "technology" that I assume is the one used by WCAG; it
is listed in chapter 5: Terms and Definitions.
The requirement for a formal specification or recommendation works for most
technologies (HTML, CSS, ECMAScript, Flash, PDF, PNG, JPEG) but may be more
problematic for others (vendor-specific HTML extensions, the currently
non-standerdized XMLHttpRequest object, ...).
In BenToWeb, we sometimes reference browser vendor documents, even though
the stability of the URLs and the completeness of the documentation can be
questioned.


>For the "technicalSpec" element type, "baseline" attribute, what does it mean
>for the purposes of this document for "something" (what is "something"?) to
>be "inside" or "outside" of the "baseline"? (I know that there is some
>discussion in the WCAG WG currently on baselines).

The "baseline" attribute can be used on the "technicalSpec" element and/or on
the "testElement" element. I couldn't think of a term that covers both;
hence "something".
Whether WCAG baselines will only contain complete technologies or also
mention specific features is an issue that still needs to be discussed by the
Working Group. There was a thread on this in March, in which I expressed some
arguments in favour of very granular baseline information [3].
WCAG conformance claims don't need to specify what technologies were used
outside the baseline, but I think test case metadata need to be more precise
in this area.

Best regards,

Christophe Strobbe


>Thanks and best wishes
>Tim Boland NIST
>
>[1]: http://www.w3.org/QA/WG/qaframe-primer

[2] http://www.w3.org/TR/2005/NOTE-test-metadata-20050914/#version-def
[3] http://lists.w3.org/Archives/Public/w3c-wai-gl/2006JanMar/0585.html



-- 
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 Monday, 28 August 2006 14:30:25 GMT

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