summary of changes etc to address issues from structure reviews

Hi,

Below is a summary of changes and comments to address the issues that 
came out of the last round of structure reviews.


Q (Many questions about what needs to be checked (links in metadata 
vs test files), against which "correct format" (IDs etc), where 
submitter info is available,...)
A The checklist for structure review 
<http://www.w3.org/WAI/ER/tests/process#structure> has been 
rearranged to provide better guidance to reviewers.
   With regard to level identifiers for SC's: this has been clarified 
in the naming convention 
<http://www.w3.org/WAI/ER/tests/usingTCDL#naming> (until the new 
convention is implemented).


Q Versioning for WCAG drafts and techniques in the metadata
A Metadata deliberately reference dated versions of WCAG documents; 
this avoid ambiguity after the publication of new drafts (i.e. Has 
test case X been reviewed against current or previous draft?)


Q Reviewer needs the title of the SC, not just the SC number
A pending action: integrate SC text into HTML view of metadata.


Q What software is needed to correctly run a test case?
A The 'technology' section in the metadata lists all technologies 
that are assumed to be supported.


Q Inconsistency of location of video files.
A Issue fixed in test metadata: directory structure 
<http://www.w3.org/WAI/ER/tests/usingTCDL#structure>


Q Some test files don't validate.
A This is only allowed if it's part of the purpose of the test 
sample; the reason for validation errors needs to be mentioned in the 
'purpose' section of the metadata.


Q What is the definition of a "correct link"?
A A link that is not broken and gets to the resource one would 
expect. [Note: we haven't documented this anywhere.]


Q What is the definition of "correct spelling"?
A The purpose of the structure review with regard to spelling is to 
detect and fix spelling errors like missing letters and transposed 
letters and similar typos that create words that don't exist or that 
have a different meaning than was intended. (We don't have a 
definition of correct spelling. Should we say "correct present-day spelling"?)
Some test samples may use British spelling instead of American 
spelling; that should be allowed.


Q Is the "testelement" section still correct in light of recent WCAG evolution?
A The testelement section should reflect what is used in the test 
file (if it is important for the test to go into this level of 
detail) and is independent of WCAG.


Q Required "file" element MUST contain one of four choices 
(http:GetRequest, http:PostRequest, ....). What if none of these is listed?
A In that case, the test sample fails the structure review. Code like
   file xlink:href="../testfiles/sc1.2.1_l1_001.html
needs to be replaced with a http:GetRequest element. [@@ We need an 
action item for this.]


Q Consistency of titles: some test sample titles are not consistent 
with the content.
A Needs to be checked on a case by case basis. We need to keep this 
in mind for the next round of reviews (after the migration to the 
next WCAG 2.0 draft).


Q Should the test purpose somehow be included in the HTML files?
A The current approach is not to do this in order to avoid 
duplication and to keep the test files minimal.
(Admittedly, integrating certain metadata into the HTML may be useful 
in a test harness; it may be possible to do this on the fly, at least 
for some of the test samples.)


Q Some other comments/questions:
A - Metadata files can be validated with many XML editors (assuming 
they support XML Schema) and online, e.g. Validome: 
<http://www.validome.org/xml/>. A validating XML editor should also 
complain if a link to one of the schemas does not work.
   - Metadata files should also be checked with the ISO Schematron 
(see instructions at <http://bentoweb.org/refs/TCDL2.0/tsdtf_schematron.html>).
   - The attributes "complexity" and "primary" have been removed.

Best regards,

Christophe


---
Please don't invite me to LinkedIn, Facebook, Quechup or other 
"social networks". You may have agreed to their "privacy policy", but 
I haven't.

-- 
Christophe Strobbe
K.U.Leuven - Dept. of Electrical Engineering - SCD
Research Group on Document Architectures
Kasteelpark Arenberg 10 bus 2442
B-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 Tuesday, 29 April 2008 14:41:28 UTC