Re: ACTION: Locations for the test samples

Hi Group,

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.
Test case authors (;)): Might be difficult to point to rendered page 
(must setup server). More overhead having both pointers.

Some more specific issues below:

Christophe Strobbe wrote:
> 
> 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?

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. For predefining a user 
input for instance we could probably use the expertGuidance element and 
give to the evaluator a strict "procedure" (ex. what to type in a input 
box). Or in case of agent evaluation the request is already defined 
using the HTTP in RDF vocabulary (as Christophe mentions). In such a 
case we could be able to set the pointers. Maybe special cases are 
forwarding that returns a completely different page (??).

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.


> 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.)

Interesting point. I find Javascript case more "problematic" and the 
only I can think in order to be consistent is to rely only on XPath (on 
generated DOM ??). But what about in case a new win is created or 
reloading etc?? :(. 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"?

 From another point of view, JS case might not cause any consistency 
problem as the "generated code" in this case is actually code, so we 
could probably point to it. In other words, what we really care isnt 
what the "client" receives (??) Couldnt we simply point to js handlers??

> 
>> 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?

Just some thoughts for discussion.

Best regards,
Vangelis

-- 
---------------------------------------------------------------
Evangelos Vlachogiannis
Researcher - PhD. Candidate
Contact: http://www.syros.aegean.gr/users/evlach/contactme.php
---------------------------------------------------------------

Received on Thursday, 11 January 2007 22:55:55 UTC