Re: Issues from structure reviews

Hi,

At 20:29 1/04/2007, Shadi Abou-Zahra wrote:
>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)

That sounds like an action item for CarlosV ;-)


>>>* 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.

This info is not stored in our XML metadata, so we only need to 
indicate it in the checklist for structure review (I see that  Shadi 
has already done this) and on the submission form.


>>>* 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.

I suppose this should go in the checklist for structure review.


>>>* 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...

And I repeat that confirmation.
The only changes that we will make is the addition for rules when 
newer drafts of WCAG 2.0 are published. We might also add rules for 
other accessibility guideline documents (but don't count on it), but 
we have no intention of removing what is already there.


>>>* 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...

I am also keeping the TCLD 2.0 XSD up to date, so validation should 
help you here.


>>>* 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.

Done. See http://www.w3.org/WAI/ER/tests/usingTCDL#naming


>>>* 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?

At the moment, I don't have a preference.


>>- 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 they 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.

Should I define the default values of "atomic" and "primary" as, 
respectively, "simple" and "true" in the spec?
Of course, we'll also have an automated check for the values allowed 
by the Task Force.


>>- 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?

My preference would be a link to an HTML version of the metadata. 
This HTML version would contain the links to the test files. The test 
files, however, don't contain a link to the metadata.


>>- 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?

Yep. Does anybody know a pill or something that would allow me to 
dispense with sleep? ;-)

Best regards,

Christophe



>>[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 |
>

-- 
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 Thursday, 5 April 2007 19:31:24 UTC