[Design] - Making Question Set Editor and QuML Player QuML Compliant
- 1 Background
- 1.1 Question metadata which has some differences from the QuML specs are:-
- 1.1.1 responseDeclaration
- 1.1.1.1 Proposed Solution for responseDeclaration
- 1.1.1.1.1 Editor Changes:
- 1.1.1.1.2 Player Changes:
- 1.1.1.1 Proposed Solution for responseDeclaration
- 1.1.2 media
- 1.1.2.1 Proposed Solution for media
- 1.1.2.1.1 Editor Changes:
- 1.1.2.1.2 Player Changes:
- 1.1.2.1 Proposed Solution for media
- 1.1.1 responseDeclaration
- 1.2 QuestionSet metadata which has some differences from the QuML specs is:-
- 1.2.1 timeLimits
- 1.2.1.1 Proposed Solution for timeLimits
- 1.2.1.1.1 Editor Changes:
- 1.2.1.1.2 Player Changes:
- 1.2.1.1 Proposed Solution for timeLimits
- 1.2.1 timeLimits
- 1.1 Question metadata which has some differences from the QuML specs are:-
Background
While comparing the existing inQuiry question and question set metadata with QuML specs we found a few gaps. Below are the properties having some differences from the QuML specs:
Question metadata which has some differences from the QuML specs are:-
responseDeclaration
media
responseDeclaration
Currently, the responseDeclaration
is stored in the below format but maxScore
is not allowed in it and outcomes
property is not allowed inside correctResponse
"responseDeclaration": {
"response1": {
"maxScore": 1, // maxScore is not allowed here
"cardinality": "single",
"type": "integer",
"correctResponse": {
"value": "0",
"outcomes": {
"SCORE": 1
} // outcome is not allowed here, only property ‘value’ is allowed
},
"mapping": []
}
}
Proposed Solution for responseDeclaration
Editor Changes:
Instead of keeping maxScore
and outcomes
in responseDeclaration
we can store maxScore
in outcomeDeclaration
as below:
"outcomeDeclaration": {
"maxScore": {
"cardinality": "single",
"type": "integer",
"defaultValue": 3
}
},
We will not store outcomes.score
inside correctResponse
because maxScore
and outcomes.score
holds the same value.
For newly created single select MCQ question responseDecleration
and outcomeDeclaration
will be stored in the below format:
"responseDeclaration": {
"response1": {
"cardinality": "single",
"type": "integer",
"correctResponse": {
"value": 2
},
"mapping": [
{
"value": 2,
"score": 3
}
]
}
},
"outcomeDeclaration": {
"maxScore": {
"cardinality": "single",
"type": "integer",
"defaultValue": 3
}
}
For multi-select MCQ, responseDecleration
and outcomeDeclaration
will be in the below format:
We will store the maxScore
inside the outcomeDeclaration
property for new question creation using v2 API.
No Data Migration (Recommended)
We will do these changes as part of the v2 API and will give the data in the above format.
If a user edits the old question using v2 API, We will store
maxScore
inside theoutcomeDeclaration
and remove themaxScore
from theresponseDeclaration
.
Data Migration (Not Recommended)
We can do the data migration for the old questions and update the question metadata with the format mentioned above.
This solution is not recommended because, with the migration of old questions, the old mobile app will break.
Player Changes:
The player will check if the question is having the
outcomeDeclaration
in the metadata of the question and what’s themaxScore
value present in it.If the
outcomeDeclaration
property is found then the player will use it as is it.If the question does not have the
outcomeDeclaration
property in the metadata then the player will look for themaxScore
property in theresponseDeclartion
.
media
Currently, Question metadata contains media in the below format:
As per QuML specs, it should be stored in the below format:
Proposed Solution for media
Editor Changes:
Update QuML specs (Recommended)
If we can update the QuML spec then change will not be required in the editor and player.
No Data Migration (Recommended)
If we are not updating the QuML specs then we have to do the following changes:
For the new question creation, we will store the media in a new format using v2 API.
If the user edits the old question using v2 API, we will check if the
type
is present in the media object, and convert it tomediaType
while editing the question.
No migration (Not Recommended)
We can do the data migration for the old questions and update the question with the above-mentioned format.
This solution is not recommended because, with the migration of old questions, the old mobile app will break.
Player Changes:
(Note: Following changes will not be required if we are updating the QuML specs as mentioned above).
The player will first check if the question media have
mediaType
property if not it will check intype
property.
QuestionSet metadata which has some differences from the QuML specs is:-
timeLimits
timeLimits
Time limits are currently being stored in the question set metadata as below:
The use of maxTime
is to show the timer on the QuML player and the use of warningTime
is to indicate the time remaining to complete the question set.
But as per the QuML schema, timeLimits
` should be stored in the below format:
Proposed Solution for timeLimits
We can set the timeLimits
for the question set as:
If we have a time limit for each of the questions we will store the timeLimits
to the question set metadata as:
If we want to store max
and warn
value but don't want to store min
value we can store the data in the below format:
We will have to update the QuML spec so the warn time should be stored inside timeLimits
Editor Changes:
No Data Migration (Recommended)
For the new question creation, we will store the
timeLimits
in a new format using v2 API.If the user edits the old question using V2 API, we will check for the
timeLimits
if it's present in the old format we will convert it to the new format on save.
Data Migration (Not Recommended)
we can do the data migration for the old questions and update the question with the above-mentioned format.
Player Changes:
The player will first check if the question has timeLimits.questionset
it will take the min
and warn
value from there, if timeLimits.questionset
is undefined and timeLimits
directly contains maxTime
and warningTime
it will take the value from there.