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:

responseDeclaration

A "responseDeclaration" contains information about the response to a question: When is it correct, and (optionally) how is it scored?

• responseDeclaration.mapping

• maxScore

Here are the differences for each question type:

Subjective Question:

Multiple Choice Question:

Multi-select MCQ:

Open Question:

For MMCQ, What would be the value of type? if correctResponse has value as an array.

media

No changes are required from the editor and player side.

timeLimits

• showWarningTimer

• warningTime(%)

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.

Warning time will be removed from the editor and moved to the player side.

In order to achieve this, the player will introduce two new properties as part of the player configuration.

1. Warning time will not be present in timeLimits and will be calculated based on the warningTime config and the Max time

2. warningTime [number (%) ] to be introduced as part of the global config. Default value of Warning timer can be 75(%) of the max time

   1. ie, Warning timer will start showing once the user finishes 75% (default) of the max time

   2. For eg, max time is 100 seconds, warning timer will start showing from the 75 seconds

3. showWarningTimer [boolean] to be introduced as part of the global config - Player

   1. This will decide if the WarningTimer has to be displayed or not

Here’s the sample player configuration.

1{ 2 'context': { 3 ... 4 }, 5 'metadata': { 6 ... 7 }, 8 'config': { 9 'sideMenu': { 10 'enable': true, 11 'showShare': true, 12 'showDownload': true, 13 'showReplay': false, 14 'showExit': false, 15 }, 16 showWarningTimer: true, // true or false 17 warningTime: 75 // [number (%) ] 18 } 19}

(Note: Existing behavior of the player will be continuing as it is for the warning indicator)

Editor Changes:

• The warning timer will be removed from the editor form and will not save the warning time value in timeLimits.

• min time will be stored inside timeLimits as timeLimits.questionSet.min

• There will not be any field for taking user input for min time, editor will store the min time as 0 by default.

The timeLimts for the questionset will be stored in below format:

1timeLimits: 2{ 3 "description": "Time limits for the complete set and/or for each question in the question set.", 4 questionSet: { 5 min: number, 6 max: number 7 } 8}

Example:-

For storing max time( max ) as 5 minutes. It will be stored in below format.

• 5 minutes is to be converted to seconds to store the value.

• 5 minutes = 5 * 60 seconds = 300 seconds

The default value of min time ( min ) will be stored as 0

1timeLimits: 2{ 3 questionSet: { 4 min: 0, 5 max: 300 6 } 7}

Open Question

Need confirmation if timeLimits is to be stored as seconds or milli-seconds ?

maxScore

For question:

Currently, maxScore property is getting stamped in two places at the question metadata level.

As per QuML spec, maxScore should be stored under the outcomeDeclaration property.

(Notes: Samagra is using this property while printing the question paper).

For Questionset:

Open Question:

For QuestionSet, What would be the value of cardinality?

(Need to be checked with ​@Gauraw Kumar and ​@Sajesh Kayyath )

answer

In the current implementation, We are not storing the answer property for MCQ and MMCQ. but as per QuML spec, An answer is mandatory for all types of questions.

• SA – HTML

• MCQ/MMCQ – reference value for data OR actual value ?
  For example: “1,2” OR “India, US”
  (Need to be checked with ​@Sajesh Kayyath and ​@Gauraw Kumar

Subjective Question:

Multiple Choice Question:

Multi-select MCQ:

Proposed Solution

Here are the solutions for different types of the question.

Solution 1

Datatype: String

In this solution, All answers will be concatenated together under an HTML element and stamped to the answer property.
Here’s the sample HTML template for single & multi answers:

Pros:

• No QuML spec changes are needed.

• No additional data transformation is required for older questions by API.

Cons:

• Difficult to differentiate each answer by the player as it’s concatenated together under an HTML element.

• Some extra effort is required to support this format by the editor /player.

Solution 2

In this solution, Each answer will be stored separately as an element in an array.

Datatype: Array (An array of strings)

Pros:

• Easy to differentiate each answer by the player as it’s not concatenated together under an HTML element.

• Easy to manipulate UI by the player.

• Minimal changes are required by the editor and player.

Cons:

• QuML spec changes are required to support this format.

• Data transformation is required in API for older questions as it’s an array of strings.

Answer attribute conclusion:-

Solution 1 is finalised for the implementation of answer.

As the answer attribute is used only for printing/display so for the simplicity answer will be stored in the form of string with the html template as mentioned above in solution 1.

1<div class="anwser-container"> 2 <div class="anwser-body"> 3 // Anwser HTML 4 </div> 5</div>

In the // Anwser HTML actual values of answers will be stored.

For “Multiple choice Questions” the label presents in interaction options will be stored in the place of

// Anwser HTML

interactions

As part of the new implementation, We will be moving only the validation field under the response1 property. No other change.

solutions

Solutions are used to provide exemplary answers to questions aid candidates in-depth learning and enhance user’s understanding of the concepts. Multiple solutions can be configured for a question

This property supports the following types:

1. Image + Text

2. Video

• Solutions is a JSON object in key-value format. The keys in the JSON are the identifiers of different solutions for the question and values are HTML snippets for solutions.

• Solutions HTML must contain only structural and media HTML elements. There should be interactions in a solution and hence no input HTML elements. QuML players should allow the users to view the solutions if the context in which the question is being used allows the users to view the solution.

feedback

Feedback is a JSON object in key-value format. The keys in the JSON are the identifiers of different feedbacks for the question and values are HTML snippet to be shown to the student. After the response processing, the QuML player renders the feedback HTML mapped to the value that is set to the FEEDBACK outcome variable.

Feedback:

For more information, please refer to this document: ​

hints (This has to be modified by an adopter)

Similar to feedback, Hints are shown to the candidates after response processing or when the student requests for hints.

Hints is a JSON object in key-value format. The keys in the JSON are the identifiers of different hints for the question and values are HTML snippet for hints.

For more information, please refer to this documentation: ​

Only Shikshalokam is using the following format.

• Question - { hints: { en : ["string"]}}

• Also, they are storing the hints for each option under the interactions property.

Here is an example from Shikshalokam storing hint for the Question :

1{ // question metadata 2 ......, 3 4 "hints": { 5 "en": [ 6 "delhi" 7 ] 8 }, 9 ..... 10}

Proposed format for storing hint of question and for storing question hint reference in outcomeDeclaration to differentiate it from the hints of options

1{ // question metadata 2 ......, 3+ hints: { 4+ "70c82bf5-9459-4c43-8897-0e58b7e2er76": { "en": "delhi" } 5+ }, 6+ "outcomeDeclaration": { 7+ "hint": { 8+ "cardinality": "single", 9+ "type": "string", 10+ "defaultValue": "70c82bf5-9459-4c43-8897-0e58b7e2er76" 11+ } 12+ } 13}

Here is an example from Shikshalokam storing hints for each options under interactions :

1{ // question metadata 2 ....., 3 4 interactions: { 5 response1: { 6 type: "choice", 7 options: [ 8 { 9 label: "<p>option 1</p>", 10 value: 0, 11 hints: { 12 en: "test hint 1", // hints for option 1 13 }, 14 }, 15 { 16 label: "<p>option 2</p>", 17 value: 1, 18 hints: { 19 en: "test hint 2", // hints for option 2 20 }, 21 }, 22 { 23 label: "<p>option 3</p>", 24 value: 2, 25 hints: { 26 en: "test hint 3", // hints for option 3 27 }, 28 }, 29 ], 30 autoCapture: "Yes", 31 validation: { 32 limit: { 33 maxLength: 100 34 }, 35 required: "Yes", 36 pattern: "dd/mm/yyyy", 37 }, 38 }, 39 }, 40 ..... 41}

Proposed format for storing hints for each options under interactions :

1{ // question metadata 2 ......, 3 4 interactions: { 5 response1: { 6 type: "choice", 7 options: [ 8 { 9 label: "<p>option 1</p>", 10 value: 0, 11+ hint: "70c82bf5-9459-4c43-8897-0e58b7e1da64", // hints for option 1 12 }, 13 { 14 label: "<p>option 2</p>", 15 value: 1, 16+ hint: "70c82bf5-9459-4c43-8897-0e58b7e1as73", // hints for option 2 17 }, 18 { 19 label: "<p>option 3</p>", 20 value: 2, 21+ hint: "70c82bf5-9459-4c43-8897-0e58b7e1gf87", // hints for option 3 22 }, 23 ], 24 autoCapture: "Yes", 25 validation: { 26 limit: { 27 maxLength: 100 28 }, 29 required: "Yes", 30 pattern: "dd/mm/yyyy", 31 }, 32 }, 33 }, 34+ hints: { 35+ "70c82bf5-9459-4c43-8897-0e58b7e1da64": { en: "test hint 1" }, 36+ "70c82bf5-9459-4c43-8897-0e58b7e1as73": { en: "test hint 2" }, 37+ "70c82bf5-9459-4c43-8897-0e58b7e1gf87": { en: "test hint 3" }, 38+ } 39}

instructions (This has to be modified by an adopter)

Instructions on how to understand, attempt, or how the question will be evaluated.

Currently, instructions are being stored in the following format:

For QuestionSet:

For Question:

Instructions HTML also must contain only structural and media HTML elements. There should be interactions in a solution and hence no input HTML elements.