- From: Shadi Abou-Zahra <shadi@w3.org>
- Date: Sun, 01 Apr 2007 20:29:37 +0200
- To: public-wai-ert-tsdtf@w3.org
Hi, Carlos Iglesias wrote: >> * CI: The e-mail addresses of the submitters of the test >> samples are not available in the Test Sample Status List [1]. > > If they are optional then the first structure checklist point should be something like "Name and e-mail address of the submitter are available (required for non TF members);" I don't think they should be optional at all. Maybe BenToWeb can provide an alias or other email address that can be used for feedback after the end of the project? (Note that many BenToWeb participants may no longer be in the TF after the end of the project) >> * CI: What happens if there is no mention of an organization >> on whose behalf the test sample is submitted? >> CS: Once we have a form for test sample submission in place, >> the form should say that we will assume that the submitter >> submitted the test sample on their own behalf if they don't >> fill in the field for 'organization'. > > And the question is, being "organization" optional, what should be checked at structure checklist point "Organization on whose behalf the test sample was submitted (optional)" Agreed, the fact that this is optional should be indicated. >> * CI: Should the embedded JavaScript be in a separate file? >> CS: Yes, see resolution 9 January 2007 [2]. > > Then, as you noted in your previous mail [1], this should be documented somewhere. Agreed. >> * CI: What's the correct format for dates, integer and literal values? >> CS: >> - date: initial value is CVS keyword $Date$, and CVS takes >> care of the rest >> - version: initial value is CVS keyword $Revision$, and CVS >> takes care of the rest > > So, there's nothing to check here, right? You need to check that the value "$Date$" and "$Revision$" (or the CVS expansions thereof) are provided in the respective fields. >> (dc:creator and dc:rights are covered by on of the other questions; >> see the values in the TCDL template[3].) > > So, again nothing to check here. Check that the wording matches the template provided on the "usingTCDL" page (sorry, I hope we can automate this in the near future). > Is there anything to check at structure checklist point "All the dates and other integer or literal values have the correct format;"? Checking integer values is necessary for IDs, and checking the "$Date$" value is described above. >> * CI: The rule reference is not valid (does not exist). >> CS: Strangely, the rulesets.xml file on the BenToWeb site is >> out of date. This will be fixed as soon as possible. > > There's also a proposal from me about restricting rule references to WCAG 2 URIs within the scope of the TF, mainly to simplify metadata review. It's still pending of discussion. The rulesets.xml was reviewed and accepted by the TF. There is no need to further restrict or describe it, however I am worried that it changed without notice. We had confirmation that this wouldn't happen... >> * CI: What kind/version of pointers vocabulary should be used? >> CS: There was agreement that we should use HTTP-in-RDF for >> ths, but there was never a formal resolution (I checked all >> the minutes since the beginning of October 2006). The pointer >> vocabulary in TCDL 2.0 is up to date with the current >> editor's draft of HTTP-in-RDF, but the old-style pointers are >> also still there (and will be removed when HTTP-in-RDF >> becomes stable). > > I think the agreement at the begining was to use EARL staff (uri:uri and pointers), know all these has been removed from EARL and moved to HTTP-in-RDF and/or the pointers vocabulary [2] (early draft), so right know I think we don't have (and can't have due to [2] "immaturity") any stable reference so, what are we going to check against?. For now I ask you to use your imagination and do your best. Christophe and the BenToWeb folks are doing their best to keep TCDL 2.0 up-to-date with EARL and its supporting documents. Until both these are stable, I suggest the following: - if any kind of pointers or HTTP vocabulary is used, review it to your best knowledge and record any potential issues you see in the wiki; - in any case, make a record in the wiki that this part of the metadata can not be fully reviewed at the moment, and that the TF will need to revisit it before it can be considered completed. I know this is not ideal but we've just got to deal with what we have... >> * CI: Test file for sc2.5.1_l1_003 refers to another file >> called "processformdummy.html" which is not in CVS and which >> does not follow our naming convention. >> CS: The file needs to be submitted and follow our naming convention. > > Then it should be sc2.5.1_l1_00X.html and the problem that raise at this moment is that until know we only use one .html file per test sample but know we have our first test sample with 2 .html files, is this OK? > (For example we can't use sc2.5.1_l1_00X as a TS id and this is an additional structure check for consistency) Actually there is another underscore, then an additional ID for such cases (so "sc2.5.1_l1_003_01.html") but this is not documented in our usingTCDL document. It needs to be updated accordingly. >> * CI: Test file for sc2.5.1_l1_003 uses JSP, which is not >> interpreted by the W3C server. Does valid markup refer only >> to HTML or also to JSP? >> CS: Since we had a resolution that pointers refer to >> generated code, I assume that valid markup refers to HTML. > > It make sense that it only apply to HTML, CSS, SVG, MathML or whatever, not to server side scripting languages (in fact once the server has been correctly setup server side validity problems will become obvious) > What about JS? Should also be checked for validity? I don't know what "valid JavaScript" is, and if JavaScript is considered markup but I think not. Validate HTML, CSS, SVG, etc. If you happen to spot errors in the JavaScript or other scripts then you can report them but I don't think we can further specify how to test the script code. >> * CI: Does "correct links" only refer to A elements or also >> to LINK elements etc? >> CS: My understanding from earlier discussions is that LINK >> elements are also covered (i.e. basically any reference with a URI). > > Also form actions for example? > Will be "blank links" (e.g. #) allowed in same cases? What you call "blank links" are valid. So yes, for the structure review "#" is sufficient. The content review *may* reveal that such a link is not ideal or even wrong (a "blank link" is not always something wrong). > - How could we distinguish between the "unconfirmed" initial status and the "unconfirmed" status that could be the output of Step 2: Structure review in the Status list [3]? We could go either way, add another flag to describe the status or just regard the existence of a review as sufficient. What do people prefer? > - Step 2 Structure Review: "...the status flag remains set to unconfirmed and the participant notifies the submitter of the test sample. The participant may carry out minor modifications and fixes to repair or improve the structure of the test sample." > > Should TF members who are submitters also be notified? Yes, why should they not be notified? > If the participant carry out minor modifications and/or fixes, should them also be notified? Yes, I think this is best practice. > - May other metadata apart from the one required by the TF be allowed? (e.g other parts of TCDL language or other owner extensions) If not, there is several metadata in the samples that is not TF's required "Test Sample Metadata" [4], such us: > > * complexity attribute at testCase element (note that we only allow atomic test cases, so if this attribute is allowed, should we check that its value is always "atomic"?) > * primary attribute at rule element (note that we only focus on WCAG 2 test samples, so if this attribute is allowed, should we check that its value is always "true"?) I think we shouldn't allow any other metadata because we can not check it, and shouldn't be publishing something without knowing what it means. > - A link to the test sample (not the metadata) somewhere would be useful, probably at the Status list and/or the Structure and Content review. This is useful (also for the Web interface that we need to implement at some point) but it will be difficult to determine which of the files of a test sample to link to. Any suggestions? > - The Structure review process is still one of the most tedious and unpleasant things I've done lately ;o) Yes, we need to automate most of this. Any volunteers to write a small script for checking these things? > [1] - [http://lists.w3.org/Archives/Public/public-wai-ert-tsdtf/2007Mar/0023.html] > [2] - [http://www.w3.org/WAI/ER/Pointers/WD-Pointers-20070222] > [3] - [http://www.w3.org/2006/tsdtf/TestSampleStatusList] > [4] - [http://www.w3.org/WAI/ER/tests/usingTCDL#metadata] > >> [1] http://www.w3.org/2006/tsdtf/TestSampleStatusList >> [2] http://www.w3.org/2007/01/09-tsdtf-minutes#item02 >> [3] http://www.w3.org/WAI/ER/tests/scx.x.x_lx_xxx.xml 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 Sunday, 1 April 2007 19:30:18 UTC