Re: ACTION: Locations for the test samples

Hi Carlos, All,

Thanks for the summary of the issue.

At 18:50 11/01/2007, Carlos Iglesias wrote:
>Hi everybody,
>
>As per my action item from the last teleconference [1] here are some 
>thoughts about the locations consistence.
>
>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?
Also, if pointers are based on generated code, how do we point into 
DOM structures generated by client-side scripts?
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.)

>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. The problem is not feasibility but 
interoperability/compatibility of location pointers (or whatever you 
want to call it) with evaluation and repair tools.

>I'm more in favour of A, because I think it's all we need for this 
>TF and is simpler (option B may require additional changes to the 
>metadata language)

My impression is that both option A and B require changes to the 
metadata language.
Any other thoughts?

Best regards,

Christophe


>What do you think?
>
>[1] - [http://www.w3.org/2007/01/09-tsdtf-minutes.html#action04]



-- 
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
http://www.docarch.be/ 


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

Received on Thursday, 11 January 2007 20:38:53 UTC