- From: Christophe Strobbe <christophe.strobbe@esat.kuleuven.be>
- Date: Mon, 12 Feb 2007 17:03:59 +0100
- 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 (http://bentoweb.org/refs/TCDL2.0.html#edef-location). >>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, Christophe >>At 03:55 PM 2/6/2007 +0100, you wrote: >>>Hi, >>>(...) >>>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, >>> >>>Christophe >>> >>>[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 http://www.docarch.be/ Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Received on Monday, 12 February 2007 16:04:09 UTC