...
Creation side Enhancements:
Introduce “serverEvaluable“ “eval“ : {“mode“ : “client/server“} attribute at question and questionSet Object Metadata level
A new attribute in QuestionSet to be introduced to mark it for server side evaluation. The editor need to allow setting this flag on a questionSet/questions. The creation APIs would be updated to support this attribute. Any question that is marked as serverEvaluable:true “eval” : { “mode“ : “server“ } can only be part of a questionSet that is also marked as serverEvaluable:true“eval” : { “mode“ : “server“ } . Also a question set that is marked serverEvaluable:true “eval” : { “mode“ : “server“ } should only contain questions with serverEvaluable:true“eval” : { “mode“ : “server“ }.
(“serverEvaluable“evaluate at server “).
| Code Block |
|---|
//Question Set Object
"questionSet": {
“eval” : { "serverEvaluable": true“mode“ : “server“ } //#true for Server Side Valuation Default:#false for client side validation
}
//Question Object
"question" : {
"serverEvaluable": true“eval” : { “mode“ : “server“ }
} |
Consumption side Enhancements
There are two modes of accessing questionSet post this proposed change:
a) client-evaluable mode : default ( serverEvaluable In case eval attribute does not exist or is falsemode = client)
In this mode, the player uses the new POST questionSetHierarchy to fetch the hierarchy, question list API to fetch question body and the content state update API to submit the ASSESS events. There are no changes to this processing as part of this changeJWT questionSetToken need to be passed to content state update, which assist the content state update to validate request is of client or server mode. Calculation of assess score remains at client side.
b) server-evaluable Evaluable mode : serverEvaluable:trueserver
| Info |
|---|
Content Compatibility needs to be set to higher value so that discovery on older clients dont happen for this questionSet |
We are proposing that, in this mode, the player uses a new API for questionSetHierarchy, the existing question list API and the existing Content State Update API without passing “score” & “pass” & . Content State Update will fetch “score“ & “pass“ using new submitAssessment APIInquiry Assessment API which introduced as part of this feature.
QuestionSet Hierarchy API (new POST API)
...
| Code Block |
|---|
"request": {
"contentID": "",
"collectionID": "",
"userID": "",
"attemptID": "" ,
"evalMode" : "server/client"
} |
This API would handle shuffling of options , selection of a subset of questions and randomisation (currently done by player) as indicated by the metadata in the questionSet. The API will also return a “QuestionSetToken“ which is a signed token which has contains user-id, content-id, collection-id,attempt-id+selected_questionid_list recieved , eval mode as part of hierarchy payload. This token will further be passed to Content State Update & to new submitAssessment API from Content State Update.“QuestionSetToken“ will be validated by submitAssessment API call.
...
| Info |
|---|
QuestionSetToken : This key is almost equivalent of jwt token created as follows: “questionSetToken“ = > { “timestamp”: epoch{ "contentID":"do_11381896937577676811", "collectionIDevalMode":"server", "userIDcollectionID":"do_11381130283086643213", "attemptIDuserID":"user-id", “questionList“: [“< "questionList":"<do-id-1>“>,”<<do-id-2>”>,…..”<<do-id-n>”] >", "attemptID":"attempt-id" } } |
2. Updates to QuestionList API
Question Read API : Any Question Associated with serverEvaluable eval-mode-server behaviour to trim off response declaration from Question Set and other answer displayed reference parameters in the response.
...
There are multiple attributes which persists correct answer in QuML
a) responseDeclaration: (Shown above)
b) answer
c) editorState
3. SubmitAssessment Assessment API to evaluate user responses & calculate score.
QuestionResponseValidateAPI (Sync API Behaviour):
...