RE: Issues from structure reviews


> Since today's telecon was cancelled, I hope we can discuss 
> and solve a few issues on the mailing list.

Let's try ;)

> * 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);"
> * 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)"

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

>   (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. Is there anything to check at structure checklist point "All the dates and other integer or literal values have the correct format;"?

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

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

> Any other comments?

A few more:

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

- 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?
If the participant carry out minor modifications and/or fixes, should them also be notified?

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

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

- The Structure review process is still one of the most tedious and unpleasant things I've done lately ;o)

[1] - []
[2] - [] 
[3] - []
[4] - []

> [1]
> [2]
> [3]


Carlos Iglesias

CTIC Foundation
Science and Technology Park of Gijón
33203 - Gijón, Asturias, Spain 

phone: +34 984291212
fax: +34 984390612

Received on Wednesday, 28 March 2007 15:35:37 UTC