Re: ACTION: Locations for the test samples


I think the location of the error depends on what has been tested and 
must therefore be specified by the test procedure. Here are two 
scenarios I am thinking of:

SCENARIO 1: The test is carried out on the script code and so the 
location of the error will be in the source files; the source files must 
be specified by the test sample, the generated content is unimportant.

SCENARIO 2: The test is carried out on the executed code and so the 
location of the error will be in the generated content; the exact 
execution parameters must be specified by the test sample.

If this type of information about carrying out the test is not part of a 
test procedure, than we should send this as a bug report to the WCAG WG.


Carlos Iglesias wrote:
> Hi everybody,
> Comments inline:
>> I would like to start thinking on that problem looking that 
>> from different stakeholders point of view:
>> Evaluation Tool Developers: For tools aiming at just 
>> evaluating rendered pages I don't think source pointer would 
>> be useful. Regarding tools that aiming at source code level 
>> (don't know any yet!) such an info could be useful.
>> Authoring Tool Developers: Same applies here.
>> User Agent Developers: Don't care about server-side probably 
>> care about js.
>> Web Content Developers or even for education purposes: Both 
>> pointers would be useful.
> Totally agree.
>> Test case authors (;)): Might be difficult to point to 
>> rendered page (must setup server). More overhead having both pointers.
> It's suppossed you (or the TF) need to test the test cases at some point, so you need to setup a server anyway.
>>>> As you can see, in example sc2.5.1_l1_003 the locations 
>> refer to the 
>>>> server-side language (JSP in this case) not to the interpreted 
>>>> content (what an user agent gets).
>>>> (...)
>>>> This is obviously a problem that increases when you use 
>> server-side 
>>>> languages in an extensive way, and raises the following question:
>>>> Should the location pointers refer to the source language 
>> or to the 
>>>> interpreted content?
>>>> IMO the locations should at least refer to the interpreted 
>> content, 
>>>> because it's the content all user agents get (most E&R tools 
>>>> included), and it's the only thing you have when you can't 
>> access to 
>>>> the files at the server.
>>> I agree that this is a problem, but I don't know how to solve it.
>>> Pointers into the generated code can't always be given if 
>> the server 
>>> response depends on form input, for example. If we want reliable 
>>> pointers into generated code that depends on form input (or 
>> on other 
>>> parameters, such as those used in content negotiation, that 
>> are used 
>>> at the server side to generate the response), I don't see 
>> how we can 
>>> do that without pulling some of the HTTP in RDF vocabulary (already 
>>> used in the 'files' element in TCDL) into the location 
>> element. It is 
>>> probably feasible, but it is much more work for test case 
>> authors than 
>>> just pointing into the source code of the test samples. Is that the 
>>> way to go? Any other solutions?
> I agree that is such cases (e.g multiple request-response) it could be much more work, but I think the question is, do we need that "extra" work?
>> I think that in case of server-side scripting in the context 
>> of this task force we could probably simplify things. In real 
>> scenarios the uncertainty of user/agent input/request cannot 
>> be predetermined so the generated markup cannot be predicted 
>> so that we can set the pointers. 
>> Fortunately ;), in case of test samples IMO everything could 
>> be strictly predetermined, even the user/agent input/request. 
> Also agree.
>> Now, regarding the different ways of rendering (mentioned in 
>> teleconf) we could probably assume a default (w3c) rendering 
>> and probably document that somewhere. Alternatively we could 
>> rely only on XPath (or
>> XPointer??) location.
> We may also have problems using Xpath (or Xpointer) in non-XML content. Are we going to restrict test samples to xhtml language? What about other non-XML contents? (CSS, JS...)
>>> Also, if pointers are based on generated code, how do we point into 
>>> DOM structures generated by client-side scripts?
> Maybe we need generated content pointers in same cases, both types of pointers sometimes, and probably never only the source pointers (see the explanation about different use cases at the beggining)
>>> If we point into the author's source code for test files with 
>>> client-side script, and into generated code for test files with 
>>> server-side script, do we have a consistency issue? (Note 
>> that a test 
>>> sample can use both server-side and client-side script.)
> I think that there is not consistency issue if this is the rule we decide to follow and we document it.
>> [..] On the other hand, 
>> during last teleconf we decided not to include any script in 
>> testfiles. So if we want to point to js source how we do? Are 
>> we allowed to point to files outside testfile or should we 
>> consider that as "generated inline"?
> Js, css... files are also test files, but we need something to associate each point with each testfile.
>>>> So, I think the only feasible options we have are:
>>>> A - Use locations only for the interpreted content.
>>>> B - Use both locations, for the original code and the 
>> interpreted code 
>>>> at the same time.
>>> C - Use locations only for the source code - is also a *feasible* 
>>> option. 
> C option looks only "feasible" for the use case of E&R tools that aim at the source code level (see the use cases explanation at the begining), if there is any of them.
>> The problem is not feasibility but 
>>> interoperability/compatibility of location pointers (or 
>> whatever you 
>>> want to call it) with evaluation and repair tools.
> I think there is not such a interoperability/compatibility problem, depending on the use case you will need one class of pointers or the other.
> Regards,
>  CI.
> --------------------------------------
> Carlos Iglesias
> CTIC Foundation
> Science and Technology Park of Gijón
> 33203 - Gijón, Asturias, Spain 
> phone: +34 984291212
> fax: +34 984390612
> email:
> URL:

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 |

Received on Monday, 15 January 2007 13:09:17 UTC