[QTI] printedVariable and response variables

[Steve Lay]

Response variables are prone to misunderstanding because they might have 
transient values during the interaction phase of an attempt.  A system 
might maintain an internal value while the user is operating the 
interactions to which the response is bound (think about typing in to a 
text field).

This raises the question of *when* the value of the response variable 
should be taken for printing with printedVariable.  A possible 
formulation (the only sensible one IMHO) would be that the response 
takes the value it did at the end of the last attempt, or the default 
value if this is the first attempt.

If you have use cases where relaxing this definition makes sense then 
I'd encourage you to submit these to IMS.

Unfortunately, such a change might lead to content that isn't compatible 
with the early 2.x implementations (as they might not implement the 
printed responses).  In which case, you might be safer using the outcome 
method anyway.

Any comments from implementers?

Steve

PS: I'm no longer the co-chair of the IMS Project Team so this is just a 
personal view.  Please contact Kevin Riley or Lisa Mattson at IMS for 
official enquiries about IMS QTI.


Daniel Cassidy wrote:
> Hi all,
> 
> The QTI 2.1 draft spec says:
> 
> 	The values of response variables cannot be printed directly
> 	as their values are implicitly known to the candidate
> 	through the interactions they are bound to. If necessary,
> 	their values can be assigned to outcomes during
> 	responseProcessing and displayed to the candidate as part of
> 	a bodyElement visible only in the appropriate feedback
> 	states.
> 
> This seems to me to be a bit arbitrary. Is there any technical
> reason for imposing this restriction?
> 
> Thanks,
> Dan.
> 
> _______________________________________________
> IMS-QTI mailing list
> IMS-QTI at lists.ucles.org.uk
> http://lists.ucles.org.uk/lists/listinfo/ims-qti