Summary on location pointers (now with the actual summary)

Hi,

[Eudora lost her patience before I had finished my mail and sent it 
before I had compeleted it. ;-)]

Some time ago, we started a discussion on location pointers in TCDL. 
Since that issue is on the agenda of today's telecon, I thought it 
would be useful to summarize the thread that started on 11 January 
(http://lists.w3.org/Archives/Public/public-wai-ert-tsdtf/2007Jan/0008.html).

The issue that started the discussion is the fact that location 
pointers for test samples using server-side code (JSP) refer to the 
server-side code and not the generated code.

Carlos Iglesias argued that the locations pointers should refer to 
the generated code. This is what all user agents and ERT get.

Vangelis pointed out that ERT could also analyse source code, and 
that AT developers would also benefit from having location pointers 
for server-side code. [Accessibility checkers embedded in some AT 
would also fit into this category.] UA developers don't care about 
server-side code, but locations in client-side script are important. 
Web content developers can use both types of pointers.

Shadi argued that the location depends on what has been tested, and 
that depends on the test procedure in the relevant WCAG technique/failure.

Sometimes, the generated code depends on user input or a specific UA 
request, so different HTTP requests may result in different error 
locations in the generated code. Vangelis said this can probably be 
solved by stating what user input is needed in the expertGuidance 
element. For generated code that depends on specific HTTP headers 
etc, we can use the HTTP in RDF vocabulary that is already available 
in the 'file' element.

Another issue that was highlighted in the thread was locations for 
test samples with client-side script code. In an earlier discussion, 
people found that JavaScript and CSS should always be stored in 
separate files instead of in the XHTML files. So location pointers 
for test samples with JavaScript would need to refer to the 
JavaScript files (line and column numbers, because we have nothing 
better). Are there any objections or further thoughts with regard to this?

Regarding Shadi's point about the type of location pointers depending 
on the test procedure: some procedures for script-based content are 
purely based on the generated code ("On a Web unit that uses scripts 
to enforce a time limit, wait until the time-out has expired.") while 
others require code review ("Examine the source code and check that 
the new content is not created using document.write(), innerHTML, 
outerHTML, innerText or outerText."). In the first example, the issue 
is in the server-side code (where the time limit is defined) but 
there is nothing in the generated code that you can point to. The 
same is true for server-side code that sets HTTP headers that cause a 
redirect or a periodic refresh.

If the above solution for server-side code (expertGuidance / HTTP in 
RDF) is sufficient, then pointers into generated code may be all we 
neeed for most cases, except where we have time limits and issues 
with HTTP headers. Any other thoughts?


Best regards,

Christophe


-- 
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
tel mobile: +32 473 97 70 25
fax: +32 16 32 85 39
http://www.docarch.be/  


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Received on Tuesday, 6 February 2007 12:02:01 UTC