Issues from structure and content reviews


I had an action item 
(<>) to 
compile a list of issues that resulted from the test sample reviews 
and check if/where they had been addressed.

* CI: The e-mail addresses of the submitters of the test samples are 
not available in the Test Sample Status List [1].
CS: I though CV had an action item to create a general e-mail address 
for BenToWeb (but I can't find this in the minutes).

* CI: What happens if there is no mention of an organization on whose 
behalf the test sample is submitted?
CS: The Review Process document has been updated to say that 
organization is optional information.

* CI: Should the embedded JavaScript be in a separate file?
CS: Yes, see resolution 9 January 2007 [2].
CI: Then, as you noted in your previous mail, this should be 
documented somewhere.
CS: The section on naming conventions of "Using TCDL" [4] mentions 
that supporting files such as CSS, JavaScript and images use the same 
naming convention as the test files that they belong to. However, the 
structure review checklist does not mention that these supporting 
files need to be separate.
* CI: What's the correct format for dates, integer and literal values?
  - 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
I have an outstanding action item to automate these checks.

* The values of dc:creator and dc:rights are provided in the TCDL template[3].)
I have an outstanding action item to automate these checks.

* CI: Is there anything to check at structure checklist point "All 
the dates and other integer or literal values have the correct format;"?
SAZ: Checking integer values is necessary for IDs, and checking the 
"$Date$" value is described above.
CS: See also the above-mentioned action item.

* CI: The rule reference is not valid (does not exist).
CS: The rulesets.xml file on the BenToWeb site was out of date (not 
synchronised with CVS). This has been fixed. (It will soon be updated 
for the next WCAG 2.0 working draft.)

* 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).
SAZ: BenToWeb will keep TCDL 2.0 up^to date with EARL and its 
suggesting 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.

* 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: action item to BenToWeb to submit this file 
with the correct naming convention (and adapt the URL in 
sc2.5.1_l1_003.jsp 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. Of course, this point is 
moot when the server does not process JSP. We need to address this 
before this file can continue through the rest of the process. Shadi, 
what's the situation with regard to JSP support?

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

* CI: What should be checked for validity?
SAZ: 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.

* SAZ: Need to check that the technology that the test sample applies 
to matches the SpecNames in TCDL.
CS: I assume this belongs under structure review; I don't know yet 
how to automate this check.

Other issues had to do with the review process document, which will 
be finalized when we have closed the discussion.
I hope I did not miss anything else.


Best regards,


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 


Received on Tuesday, 15 May 2007 12:29:11 UTC