Versions Compared

Old Version 10

changes.mady.by.user Surendrasingh Sucharia

Saved on

compared with

New Version Current

changes.mady.by.user Vaibhav Bhuva

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

...

...

...

...

...

Table of Contents
minLevel1
maxLevel7

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 Response declaration responseDeclaration is stored in the below format but there are two properties that are maxScore is not allowed in it , which are: maxScore and  outcomesand   outcomes property is not allowed inside correctResponse

Code Block
"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 it maxScore in outcomeVariables outcomeDeclaration as below:

Code Block
"outcomeVariables"outcomeDeclaration": {
    "maxScore": {
      "cardinality": "single",
      "maxScoretype": 1,
"integer",
      "defaultValue": 3
    }
  },

we We will not store outcomes.score inside correctResponse because maxScore and outcomes.score hold holds the same value.

For newly created single select MCQ question responseDecleration and outcomeVariables outcomeDeclaration will be like this for single select MCQstored in the below format:

Code Block
"responseDeclaration": {
  
    "response1": {
  
        "cardinality": "single",
           "type": "integer",
           "correctResponse": {
      
        "value": "0",2
           },
           "mapping": []

      }    },
{
  "outcomeVariables": {        "maxScorevalue": 12,
   }

and responseProcessing will have above format.

For newly created question responseDecleration and outcomeVariables will be like this for multi select MCQ:

Code Block
"responseDeclaration": {        "response1score": 3
{        }
    "cardinality": "multiple", ]
    }
  },
  "typeoutcomeDeclaration": "integer",{
           "correctResponse"maxScore": {
      "cardinality": "single",
       "valuetype": [0"integer",
1],      "defaultValue": 3
    }
}

For multi-select MCQ, responseDecleration and outcomeDeclaration will be in the below format:

Code Block
"responseDeclaration": {
          "mapping"response1": [{
      "cardinality": "single",
          "responsetype": 0,
     "integer",
            "outcomes"correctResponse": {
           
        "scorevalue": 1
          [2,1]
       }
                },
      "mapping": [
        {
       
          "responsevalue": 12,
          "score": 0.5
      "outcomes": { },
        {
          "scorevalue": 1,
          "score": 0.5
      }  }
      ]
    }
  },
  "outcomeDeclaration": {
    "maxScore": {
 ]     "cardinality": "single",
 }    },    "outcomeVariablestype": {"integer",
       "maxScoredefaultValue": 1
2,    }

Implementation approach

  • With Migration

we can do the data migration for the old questions and update the question with above mentioned format.

  • Without Data Migration

For the new question creation we will store the maxScore inside the outcomeVariables.

...


  },

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 the

...

    • outcomeDeclaration and remove the maxScore from

...

    • the responseDeclaration.

  • 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 the maxScore 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 the maxScore property in the responseDeclartion.

media

Currently question , Question metadata question contains media in this the below format:

Code Block
"media": [{
   "id": "do_2136952965043896321346",
   "type": "image", //instead of ‘type’ it should be ‘mediaType’
   "src": "/assets/public/content/assets/do_2136952965043896321346/mountain.jpeg",
   "baseUrl": "https://dev.inquiry.sunbird.org"
}]

As per QuML specs, it should be stored in the below format:

Code Block
"media": [{
   "id": "do_2136952965043896321346",
   "mediaType": "image",
   "src": "/assets/public/content/assets/do_2136952965043896321346/mountain.jpeg",
   "baseUrl": "https://dev.inquiry.sunbird.org"
}]

  • With Migration

we can do the data migration for the old questions and update the question with above mentioned 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 to mediaType 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 in type property.

...

QuestionSet metadata which

...

has some differences from the QuML specs is:-

  • timeLimits

timeLimits

Time limits is are currently being stored in the question set metadata in as below format:

Code Block
languagejson
timeLimits: {
   "maxTime": "240",
   "warningTime": "60"
}

The use of maxTime is to show the timer on questionset the QuML player and the use of warningTime is used to show the timer in red color indicating your are left with only these few minutes indicate the time remaining to complete the questionsetquestion set.

...

But as per the QuML schema it , timeLimits` should be stored in the below format:

Code Block
languagejson
timeLimits:
{
  "description": "Time limits for the complete set and/or for each question in the question set.",
   questionset: {
           min: number,
           max: number
   },
   question: {
           min: number,
           max: number
   }
}

Proposed Solution for timeLimits

We can set the limit timeLimits for the complete question set as:

Code Block
languagejson
timeLimits:
{
   questionset: {
           min: number,
           max: number,
           warn: number // update the QuML specs
           
   }
}

If we have the a time limit for each of the question questions we can will store the time limit timeLimits to the question set metadata as:

Code Block
languagejson
timeLimits:
{
   question: {
           min: number,
           max: number,
           warn: number // update the QuML specs
   }
}

Note: The timer field in the question set editor is part of the common form which is taking maxTime and warningTime as input.

We can keep on using the same configuration for the field in the form configuration keeping maxTime and warningTimeand in editor code we can handle maxTime with max and warningTime with min.

  • With Migration

we can do the data migration for the old questions and update the question with above mentioned format.

...

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:

Code Block
languagejson
timeLimits:
{
   questionset: {
           min: null,
           max: 240,
           warn: 60
           
   }
}

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 have has timeLimits.questionset it will take the min and max warn value for from there, if timeLimits.questionset is undefined and timeLimits directly contains maxTime and warningTime it will take the value for from there.