brianjmiller
commented
6 years ago Always open to interpretation, but I would suggest it is not "just an array of strings". It could depend on whether the interaction type is being specified. In the case that the type is specified I think the requirements to conform to the existing formats becomes more strict. The spec does indicate:
It is expected that Communities of Practice requiring richer interactions definitions will do so through the use of Activity types and Activity Definition Extensions.
But short of that, if the interactionType is specified you get into territory which includes:
From the spec on the response pattern:
The table below outlines the format of the strings within "correctResponsesPattern" property for each interaction type. This format is also used to represent the learner's response within the Result Object. These formats were originally based on the requirements relating to "cmi.interactions.n.correct_responses.n.pattern" as defined in the SCORM 2004 4th Edition Run-Time Environment.
Which is then extended to the correctResponsesPattern to match against the format listed above.
The table below outlines the format of the strings within "correctResponsesPattern" property for each interaction type. This format is also used to represent the learner's response within the Result Object. These formats were originally based on the requirements relating to "cmi.interactions.n.correct_responses.n.pattern" as defined in the SCORM 2004 4th Edition Run-Time Environment.
Also note, while the xAPI spec referenced the SCORM 2004, 4th ed. the formats of these values actually reference an IEEE standard which was the basis of the SCORM2004 values, see IEEE 1484.11. Adhering to them as a standard, particularly with the effort to standardize xAPI is probably wise.
Note any value can be recorded via extensions. If a better format is to be written, it might make sense to include it there and publicize that extension. Having said that, there is a lot of thought (not by me) that has gone into these formats.
Other things to consider: https://github.com/adlnet/xAPI-Spec/issues/628 https://github.com/adlnet/xAPI-Spec/issues/630
garemoko
While the 'or' functionality is available in the guise of an array (of possibilities), this solution can become very quickly difficult to maintain when you need to work with a question that necessitates multiple answers and on for each answer there are multiple possibilities. Take for example a fill-in text where each blank can receive multiple correct possibilities. You can see how the correctResponsesPattern could exponentially grow and become rather cumbersome. A syntax using an OR operator such as [|] could be highly profitable in such an occasion, something like: optionA1[|]optionA2[.]target1[,]optionB1[|]optionB2[.]target2...