-
Notifications
You must be signed in to change notification settings - Fork 404
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow for an 'OR' operator in the correctResponsesPattern #1074
Comments
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:
But short of that, if the From the spec on the response pattern:
Which is then extended to the
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 |
The correctResponsesPattern doesn't have to be exhaustive so you don't have to include every possible combination. If there really are a huge number of possible correct combinations then I would question how useful that data is anyway; how is a reporting tool going to represent that? Also consider that what you're representing as a single question may be more simply represented as multiple questions. Do you have a real example? |
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...
The text was updated successfully, but these errors were encountered: