W3C home > Mailing lists > Public > public-wai-ert-tsdtf@w3.org > February 2007

Re: Wiki: proposals for templates and index page available for review

From: Christophe Strobbe <christophe.strobbe@esat.kuleuven.be>
Date: Mon, 12 Feb 2007 17:03:59 +0100
Message-Id: <>
To: public-wai-ert-tsdtf@w3.org

Hi Tim,

Thank you for your comments and questions.

At 15:44 12/02/2007, Tim Boland wrote:

>Forwarded message (in case I didn't send it earlier)
>>To: public-wai-ert-tsdtf@w3.org
>>From: Tim Boland <frederick.boland@nist.gov>
>>Subject: Re: Wiki: proposals for templates and index page available 
>>for   review
>>If a test sample can undergo several structure reviews, does this 
>>mean that one person will do multiple reviews at different times 
>>(maybe implied since there is a "Reviewer" assigned), or different 
>>people will do different reviews?  If the latter, how do  we know 
>>who does which review?

That's a good point. Even if it is more time-efficient to have one 
person do most of the reviews of a test sample, it is good to 
accomodate the template to allow for different reviewers. (People 
join and leave the task force or may be temporarily not available, 
etcetera.) I see two ways to address this issue.
1. We move the "Reviewer" heading so that it appears above each 
review. Then it is always clear who did what.
2. We keep the "Reviewer" heading and keep it up to date with the 
current reviewer because it may not be important who did the other 
reviews? (And if you really wanted to know, you could retrieve 
earlier versions, as in every Wiki.)

Option 1 sounds better to me. For the test sample index (or status 
list [4]), I think it is sufficient to just list the current or 
latest reviewer.

>>For structure review, should there be a column for additional comments?

That sounds like a good idea.

>>Also should there be definitions of "committed",
>>"available", "valid", etc. for a reviewer to consult?

We have definitions at 
http://www.w3.org/WAI/ER/2006/tests/process#labels in our review 
process document. This process document is referenced from the Wiki's 
front page. I thought that would be sufficient, but we can also add 
the link to the template.

>>Should there be a link to "the naming conventions", "the correct 
>>format", and "the correct syntax" for the reviewer to consult?

Would it be sufficient to reference the naming conventions 
(http://www.w3.org/WAI/ER/tests/usingTCDL#naming) from the process 
document? For correct syntax of identifiers of test samples, we could 
refer to the same location.
"dates and other values use the correct format" could be made more 
specific: "date and version in 'formalMetadata' use CVS keywords 
($Date$ and $Revision$, respectively, for test cases that are first 
added to the CVS)."

>>Why is the "unintentional" in there for "broken links"?

This is to allow for intentionally broken links, in test cases where 
this makes sense. Perhaps we could reformulate this as: "there are no 
broken links unless the purpose of the test justifies/requires broken 
links" (and if links are intentionally broken, test metadata MUST 
mention this).

>>What exactly are "other values" and "other texts" (maybe some examples)?

We have fixed values for dc:creator and dc:rights. The relevant 
sections in "WCAG 2.0 Test Samples Metadata" 
(http://www.w3.org/WAI/ER/tests/usingTCDL) refer to the metadata 
template for the actual values. (Having those values - long-winded 
XML - inside the document was a nuisance for screen reader users.)

>>What does it mean for locations to be "referenced correctly" and to 
>>be "consistent with each other"?

Location poiinters, if available, must reference the actual locations 
of the issues or failures. This is not hard, but something that might 
be forgotten when test files are changed ...
Our metadata allow for different types of pointers: line and column 
numbers, XPath, ... When providing more than one type of pointer 
(each inside the same 'location' element), each must reference the 
same location. For identifying different locations, one must use 
several instances of the location element 

>>If defects are found in the structure review, how are those 
>>corrected?  Is the submitter notified?

I think I proposed that we fix the obvious issues ourselves (i.e. the 
reviewer does it and mentions it in the review report), but that we 
contact the submitter if there are several ways to fix the test 
sample or if there are other unclarities. Regarding changes and 
notifications to the submitter, we have several options (not mutually 
exclusive): sending them an e-mail, and asking them to subscribe to 
the "Recent Changes" RSS feed for the Wiki page with the reviews of 
their submission(s).

Best regards,


>>At 03:55 PM 2/6/2007 +0100, you wrote:
>>>There are two approaches available for review:
>>>* Vangelis created one template for the structure review [1], and 
>>>one for the content review [2];
>>>* I have also created a template for a page that would combine 
>>>info from structure and content reviews with info on the 
>>>contributor or source of the test sample, task force straw poll 
>>>comments (if we decide to work with straw polls) and WCAG WG 
>>>decisions/comments [3]. There would be one such page per test 
>>>sample (the ID of the test sample would match the title of the 
>>>page), which would enable us to see at a glance what has been done 
>>>for a specific test sample.
>>>I have also created a proposal for an index page [4]. This 
>>>currently contains an empty table with columns for test sample ID 
>>>(with link to web version of the TCDL metadata), a link to the 
>>>test sample's wiki page (see above), the name of the reviewer to 
>>>whom the test sample is assigned, and it's status. (It would be 
>>>even nicer if such a table could be generated automatically from 
>>>our other data ...)
>>>Links to these proposals can be found on the front page of our 
>>>Wiki at http://www.w3.org/2006/tsdtf/FrontPage.
>>>Please send comments to the list by next Monday.
>>>Best regards,
>>>[1] http://www.w3.org/2006/tsdtf/TestSampleStructureReviewTemplate
>>>[2] http://www.w3.org/2006/tsdtf/TestSampleContentReviewTemplate
>>>[3] http://www.w3.org/2006/tsdtf/TestSampleOverviewTemplate
>>>[4] http://www.w3.org/2006/tsdtf/TestSampleStatusList

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

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Received on Monday, 12 February 2007 16:04:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:00 UTC