Re: fixing the test samples (was Re: initial review of sc1.2.1_l1_002?)

Hi Shadi,

At 16:21 30/08/2007, Shadi Abou-Zahra wrote:

>Hi Tim, Christophe, all,
>I think Tim pointed out several things that need to be fixed in this 
>specific test sample. However, based upon his other review I assume 
>that these problems will be found in several test samples as we go 
>along. To save valuable time and effort I propose that we hold off 
>from doing any additional reviews and get the test samples fixed by 
>the BenToWeb folks who submitted them first.
>Christophe, if you agree then I would ask you as the facilitator to 
>contact the BenToWeb submitters and check if they could fix the samples.

Consider it done! (I mean: contacting BenToWeb submitters...).

Best regards,


>   Shadi
>Christophe Strobbe wrote:
>>Hi Time,
>>Thanks for the review.
>>At 14:35 29/08/2007, Tim Boland wrote:
>>>Initial "manual"  review of sc1.2.1_l1_002:
>>>Name and Email Address of the Submitter (File) Are Available -
>>>Not sure if files pass -
>>>I could not name and email of submitter in the metadata file itself; the
>>>submitter name is in the test sample list, but the email 
>>>associated with that submitter does not
>>>appear to me to be the personal address of the submitter (rather a 
>>>generic email
>>>address). (QUESTION: Should the name and email address of the submitter be
>>>included in the metadata file directly? - if this has already been discussed
>>>and I've forgotten, please accept my apologies). Similarly, I 
>>>could not find submitter
>>>information in the actual file).
>>Name and e-mail of the submitter are not specified in the metadata 
>>file but in the Test Sample Status List. When the test sample was 
>>submitted by or on behalf of BenToWeb, we use a generic and stable 
>>e-mail address, so that it is still possible to contact BenToWeb 
>>folks after the project ends. (See 
>>>Organization on whose behalf the test sample (file) was submitted -
>>>Not sure if files pass - this organization name is not given 
>>>explicitly in the
>>>metadata file itself (although it is given in the list of test samples); the
>>>organization may be derived by implication ("bentoweb") in 
>>>"xmlns"? (QUESTION: Should this
>>>organization be included in the metadata directly? - if this has 
>>>already been
>>>discussed and I've forgotten, please accept my apologies). 
>>>Similarly, I did not find the
>>>submitting organization mentioned explicitly in the actual file, 
>>>but it may be derived by
>>>implication from the "copyright" notification contained?
>>The "organization" is BenToWeb; this is specified in parentheses in 
>>the "Submitter" column.
>>The BenToWeb copyright notice in the test file needs to be removed 
>>because the materials are meant to be subject to W3C license after 
>>they are submitted.
>>>Test Files
>>>All the files that are necessary to execute the test procedure have been
>>>submitted -
>>>not sure? In the actual file, I could not locate (or get to play? the
>>>file "sc1.2.1_l1_002.wmv", but maybe that's just me) Also, for 
>>>link in "files" containing a file in
>>>subdirectory "testfiles", "sc1.2.1_l1_002.html", shouldn't the 
>>>path include subdirectory "video"
>>>  before the actual filename?
>>It appears that the video file ended up in the wrong location: the 
>>'video' folder is supposed to be a subfolder of the 'resources' 
>>folder; we will need to fix that.
>>>  All the submitted files follow the naming convention and 
>>> directory structure -
>>>not sure? (see note just previous) Other naming conventions and directory
>>>structure issues seem to be satisfied by these two submitted 
>>>files, except that the
>>>required "techniques" element (from the metadata document) does 
>>>not seem to be included
>>>  in the metadata file?
>>Indeed, the technique mapping needs to be added.
>>>(NOTE: The lower-
>>>case "l" and the number "1" may appear almost identical in certain 
>>>renderings - should
>>>it be considered to use upper-case "L" which might be less confusing? Just a
>>>(NOTE: There are additional elements (for example, 
>>>"functionalOutcome" and "TestElement" - twice -)
>>>included in the metadata file which were not mentioned (that I 
>>>could see) in the metadata
>>>document.. Should these be mentioned in case they have inadvertent 
>>testElements is OK (optional), but functionalOutcome needs to be removed.
>>This also implies an action item for me to check and update the 
>>XSLT that converts TCDL 1.1 (from BenToWeb) to TSDTF metadata.
>>>(QUESTION: "file" is "required" in the Test Samples Metadata 
>>>Document, but the four
>>>choices afterwards "http: GetRequest", "http: PostRequest", 
>>>"http:PutRequest", and "http: HeadRequest"
>>>are all "optional" - is it possible to have none of these four 
>>>choices included since they're all "optional"?
>>>Perhaps the document can be reworded more precisely?  In any case, 
>>>none of these strings is explicitly
>>>included after the "file" element..)
>>The xlink:href attribute is something I am a bit reluctant to 
>>remove from TCDL 2.0 until 'HTTP Vocabulary in RDF' is finalized. 
>>That said, for a simple GET request, which is what we have in this 
>>test, the file element should not use the xlink:href attribute but 
>>The intention is to get exactly one of http:GetRequest, 
>>http:PostRequest, http:PutRequest or http:HeadRequest. Should I 
>>tighten the wording in <>?
>>>All the files include valid markup unless otherwise required by the test -
>>>not sure?
>>>I ran the metadata file through Oxygen validator, and result 
>>>indicated file was
>>>valid, but I'm not sure whether I validated against schematron or 
>>>just XML schema?,
>>>since I don't know Oxygen that well yet..).
>>I don't know it either. I hope I will find some time to check in 
>>the next few weeks.
>>>For the actual file, a check of the URL
>>>against the new W3C Validator revealed four errors (was not valid 
>>>XHTML1.0 Strict - 1) line 11,
>>>column 13: there is no attribute "src", 2) line 11, column 55: 
>>>there is no attribute "loop", 3)
>>>line 11, column 72: there is no attribute "autostart", 4) line 11, 
>>>column 79:
>>>element "embed" undefined.
>>Hmm, I think the test file uses the embed as a fallback for 
>>browsers that don't support the object element. Either the valid 
>>markup requirement is a bit too tight or the purpose should mention 
>>why embed is used and that it should not be treated as invalidating 
>>the test file. Any thoughts?
>>>All the files include correct links unless otherwise required by the test
>>>- not sure? It depends on what the definition of "correct" is in 
>>>this context.. The
>>>links presented in the two files all seem reasonable, but might 
>>>need to check further..
>>The links are correct in theory, but the video file is not where it 
>>is supposed to be...
>>>All the files include correct spelling unless otherwise required 
>>>by the test -
>>>pass? A cursory examination reveals spelling seems to be correct. 
>>>I ran a spell
>>>checkers on the metadata file and "HyperText" was an unrecognized 
>>>word (suggested
>>>replacing with "hypertext")?
>>I assume you mean "HyperText" in the specName element? That is the 
>>spelling used by the XHTML spec, so that's OK. Do we need to refine 
>>the spelling requirement?
>>>All the dates and other integer or literal values have the correct format -
>>>not sure?
>>>It depends on what the definition of "correct" is in this context. A cursory
>>>examination of the formats of such values indicate that they seem 
>>>reasonable, but bears
>>>further examination..
>>>All static values (especially copyright notices) are included and accurate -
>>>pass? Copyright notices are included in both files, but for the 
>>>metadata file, the
>>>copyright notice seems to be W3C-related, whereas in the actual 
>>>file, the copyright
>>>notice seems to be "BentoWeb" related.. I can't speak fully to the 
>>>accuracy of these
>>The copyright notices are currently only available in the example file at
>><> (which is referenced from
>>The ISO Schematron file contains checks for these data.
>>>(QUESTION: I notice "Microsoft" is mentioned explicitly in the 
>>>metadata file -
>>>should there be some sort of attribution or other qualification as 
>>>to the use of a
>>>company name in this way?  There is a trademark on the XHTML 
>>>reference - maybe
>>>something similar for Microsoft as well?)
>>Your attention to detail is impressive!
>>As far as I can make out, Microsoft uses a registered sign (R in a 
>>circle) after its name. I guess we need to fix this.
>>>All titles, descriptions, and other required fields are included 
>>>and accurate -
>>>pass for metadata file? - For the actual file, see notes 
>>>previous.. Need more
>>>information on definition of "accurate"..
>>I assume we use the normal dictionary meaning ;-)
>>In my opinion the description is incomplete, because it does not 
>>say anything about the embed element.
>>Best regards,
>>>All identifiers (especially ID for techniques and rules) are used 
>>>correctly -
>>>pass? The id attribute value "sc1.2.1_l1_002" seems reasonable and 
>>>consistent with
>>>naming conventions, technique "G93" seems to be referenced 
>>>correctly, and the primary
>>>rule seems to be consistent with the BentoWeb ruleset in terms of naming
>>>(I assume the "WCAG2_20070517_1.2" and "media-equiv-captions" are 
>>>in the reference?) but didn't have time to check it further?
>>>All structures such as rules, techniques, and pointers are used correctly -
>>>not sure?  It depends upon the definition of "correct" in these 
>>>contexts - the approach
>>>seems reasonable, but without further definitions/specification 
>>>it's hard to tell?
>>>(COMMENT: It would be good to define precisely what "correct" 
>>>means, so that reviewers and
>>>submitters have more information to "get it right")
>Shadi Abou-Zahra     Web Accessibility Specialist for Europe |
>Chair & Staff Contact for the Evaluation and Repair Tools WG |
>World Wide Web Consortium (W3C)  |
>Web Accessibility Initiative (WAI), |
>WAI-TIES Project,       |
>Evaluation and Repair Tools WG, |
>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 - Dept. of Electrical Engineering - SCD
Research Group on Document Architectures
Kasteelpark Arenberg 10 bus 2442
B-3001 Leuven-Heverlee
tel: +32 16 32 85 51 


Received on Thursday, 30 August 2007 14:55:27 UTC