Regarding the possible response patterns for the numeric interaction type, my understanding is that there are four possible combinations:
'2[:]4' // would mean a minimum of 2 and a maximum of 4 (response in the range of 2 to 4 would be correct)
'4' // (no delimiter) means there is a single correct answer of 4
'4[:]' // this means a minimum of 4 and no maximum (response in the range of 4 or above would be correct)
'[:]4' // would mean no minimum but a maximum of 4.
My question relates to the last example. Would an answer of 0 (zero), or some negative number, be acceptable? The standard does not seem to make any provision for such situations and I am unclear whether values of zero or less were within the contemplation of the drafters of the specification.
Note that the response pattern '-2[:]4' works in the SCORM Cloud LRS but I am not sure whether other LRSs would accept negative range values.
This really breaks down into several parts, what values conform to which specifications and what your intended use case is, along with what we are actually seeing in the marketplace.
1) The xAPI specification is very loose on these pieces of data. Strictly speaking any string value would be acceptable as a result.response or item in correctResponsesPattern array for strict (following the MUSTs) xAPI purposes. It is left up to the implementation of the LRS if they want to be more strict, see:
An LRS, upon consuming a valid interactionType, MAY validate the remaining properties as specified for Interaction Activities and MAY return 400 Bad Request if the remaining properties are not valid for the Interaction Activity.
(Ref: 2.4.4.1 https://github.com/adlnet/xAPI-Spec/blob/master/xAPI-Data.md#requirements-4)
SCORM Cloud follows the strict model so it will only validate that those properties are strings and it takes no further action on the contents of those strings (at this time). Other LRSs may or may not be more strict about the values per above.
The operative text here is:
These types of interactions were originally based on the types of interactions allowed for "cmi.interactions.n.type" in the SCORM 2004 4th Edition Run-Time Environment.
(Ref: https://github.com/adlnet/xAPI-Spec/blob/master/xAPI-Data.md#interaction-types)
And the important phrase there is originally based on, in other words it was decided that given the extent of adoption of the CMI data model amongst LMS vendors and the corresponding content that dominated the landscape at the time it was important to at least facilitate their usage, while not interfering with the expanded scope of what xAPI offered.
2) SCORM 2004 4th edition is more strict. In the RTE reference it states:
The interaction requires a numeric response from the learner. The response is a simple number with an optional decimal point.
Later it states:
If the characterstring value is a numerical range, it shall exhibit the following format, where <min> and <max> are both of real(10, 7) data type.
So the numerical values have to be represented in the set of real(10, 7). Which is referenced elsewhere as:
The real(10,7) data type denotes a real number with a precision of seven significant digits.
(There is a note after this about how to store the values using SQL and that the designation corresponds to ISO 11404)
So if you are attempting to capture the data to be used with the SCORM 2004 information model then you should restrict your usage to that range of values.
3) In the marketplace so far I think we've mostly seen people capturing what they need to reasonably capture and the cmi.interactions are being used for the simple cases but not much beyond that. I wouldn't expect strong validation of the string contents themselves as LRSs have typically preferred to avoid attempting to derive meaning from them and there isn't a great deal of reason for an LRS (from a strictly spec standpoint) to provide such validation. It is better for the downstream systems (such as LMSs and/or reporting tools) to handle the data that they recognize as they see fit.