TSD TF

Locations in TCDL

<Christophe> Locations in TCDL: summary: http://lists.w3.org/Archives/Public/public-wai-ert-tsdtf/2007Feb/0004.html

cv: server side vs client side scripting
... generally tools view generated code

saz: when we say a test fails, what do we point to as the trigger for the failure?
... simple case, image missing alt, can point to the image and say it's missing alt
... in scripting, do we point to raw, unprocessed, server-side script page, or to generated code?
... Christophe has posted about this http://lists.w3.org/Archives/Public/public-wai-ert-tsdtf/2007Feb/0004.html

cs: generated code depends on user input; error could be in different places depending on input
... so suggest location pointer into generated code, with information about the input used
... in cases with no user input, could use HTTP-RDF to build up the appropriate headers

cv: also applies to cases with user input

saz: focus on what we need to point to

mc: asks who the pointer is for - author or evaluator - and can we count on having access to server-side code at both evaluation and report time?
... also not sure there's always a single place in server-side code where the error caused

cs: evaluators also audiences of our test suite

mc: so we're only talking about being able to point into our test suite?
... in that case maybe desirable to point to that, but unsure we need such a rich means of expression

saz: also depends on test procedure
... in some cases, test procedure just looking at the HTML seen by the browser
... if we had, e.g., PHP test procedures, then we might want server-side pointers
... also raise question of whether there is something we can point to in all cases

cv: HTTP-RDF provides most of the expression we need
... we're working mainly with generated code

saz: setting aside metadata and request headers and focusing just on pointers
... suggest default is to point to the generated content, if there's something to point to

ci: question still if there's client-side script
... so need more complete criteria

cv: but when, e.g., JavaScript changes DOM, it's the DOM you analyze
... don't typically track the place in the function where element generated

mc: sounds like, server-side or client-side, it's the results of the script we have to point to

cv: we don't have way to point to script functions etc.

saz: we track the exchange - user input and system output
... and determine if there are problems in the system output (generated code)

ci: this line of reason works if you use DOM-based scripting

mc: non DOM scripting is document.write?

cv: that's stil DOM

ci: was thinking of it as not

mc: you still get generated content, even if not referenceable by XPath

cs: how do you reference?

mc: character offset?

cv: what about alerts? need to refer to a generated element to reference

saz: also need to record user input in a different way for client-side input
... HTTP-RDF doesn't express client-side input

cs: use ExpertGuidance element

mc: for alerts, suggest using element that triggered it to appear
... for user input, should be expressable in name-value pairs

cv: also have to account for UI events
... ExpertGuidance for that

mc: can record user input into a script for playback
... though that's not all that usable except for playback

cs: e.g., for forms, you don't want something to play back, you want to provide instructions on what to put into form

mc: agree, script might not be useful, maybe store name-value for form inputs and ExpertGuidance for other relevant actions

RESOLUTION: reference generated code whenever possible; use ExpertGuidance for client-side user input; user HTTP-RDF for server-side user input

TSD TF Wiki

<Christophe> http://www.w3.org/2006/tsdtf/

http://www.w3.org/2006/tsdtf/FrontPage

cs: review templates available in wiki for group to review

<shadi> http://www.w3.org/2006/tsdtf/TestSampleOverviewTemplate

<shadi> http://www.w3.org/2006/tsdtf/TestSampleStructureReviewTemplate

<shadi> http://www.w3.org/2006/tsdtf/TestSampleContentReviewTemplate

<shadi> http://www.w3.org/2006/tsdtf/TestSampleStatusList

mc: suggest for content review template, use "how does test sample address technique" rather than "does it" to prompt more thorough review

<shadi> http://www.w3.org/WAI/ER/2006/tests/process#content

<Tim> I agree with MC

saz: have open action to update wording from checklist

but we don't have more detail there

scribe: should we work on checklist, or review sample to test process?

mc: think we need to run it through a practice, then discover weaknesses and port back to checklist as needed
... each iteration do on different test cases so we don't lose value by familiarity

cs: have some test cases available now to do this

mc: suggest some people be reviewers, and some be "reviewees" who receive reviews without having looked at test case themselves

cv: would like to finish refining the wording before we take this to experimental implementation

saz: as we modify process, will update both checklist and templates

cv: question from Tim about multiple reviews http://lists.w3.org/Archives/Public/public-wai-ert-tsdtf/2007Feb/0011.html

tb: keeping track of who's reviewing what

saz: that's what status list is for
... that links test with current reviewer

tb: could you have more than one reviewer working a particular aspect at one time?

saz: according to our process, it's sequential with each step done by a single person
... suggest organizing templates as table

<scribe> ACTION: Shadi to post wording cleanup of review checklist [recorded in http://www.w3.org/2007/02/13-tsdtf-minutes.html#action01]

<scribe> ACTION: Vangelis to tweak review templates based on discussion [recorded in http://www.w3.org/2007/02/13-tsdtf-minutes.html#action02]