Спецификация xAPI: Действия типа cmi.interaction - 'numeric'

Question

Что касается возможных шаблонов ответов для числового типа взаимодействия, я понимаю, что существует четыре возможных комбинации:

'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.

Мой вопрос относится к последнему примеру. Будет ли приемлем ответ 0 (ноль) или отрицательное число? Стандарт, похоже, не предусматривает каких-либо условий для таких ситуаций, и мне неясно, были ли значения, равные нулю или меньше, в рамках рассмотрения проекта спецификации. Обратите внимание, что шаблон ответа '-2[:]4' работает в SCORM Cloud LRS, но я не уверен, что другие LRS примут отрицательные значения диапазона.

Answer 1

Это действительно разбивается на несколько частей: какие значения соответствуют каким спецификациям и каков ваш предполагаемый вариант использования, а также то, что мы на самом деле видим на рынке.

1) Спецификация xAPI очень слаба для этих фрагментов данных. Строго говоря, любое строковое значение будет приемлемым как result.response или предмет в correctResponsesPattern массив для строгих (следующих MUST) целей xAPI. Это зависит от реализации LRS, если они хотят быть более строгими, см.:

LRS, после использования действительного Типа взаимодействия, МОЖЕТ проверить оставшиеся свойства, как указано для Операций взаимодействия, и МОЖЕТ вернуть 400 Плохой запрос, если оставшиеся свойства недействительны для Действия взаимодействия.

(Ссылка: 2.4.4.1 https://github.com/adlnet/xAPI-Spec/blob/master/xAPI-Data.md#requirements-4)

Облако SCORM следует строгой модели, поэтому оно будет проверять только то, что эти свойства являются строками, и не предпринимает никаких дальнейших действий над содержимым этих строк (в настоящее время). Другие LRS могут быть или не быть более строгими в отношении значений, указанных выше.

Оперативный текст здесь:

Эти типы взаимодействий изначально основывались на типах взаимодействий, разрешенных для "cmi.interactions.n.type" в среде выполнения SCORM 2004 4th Edition.

(Ссылка: https://github.com/adlnet/xAPI-Spec/blob/master/xAPI-Data.md#interaction-types)

И эта важная фраза изначально основана на, другими словами, было решено, что с учетом степени принятия модели данных CMI среди поставщиков LMS и соответствующего контента, который доминировал в ландшафте в то время, было важно, по крайней мере, облегчить их использование., не мешая расширению возможностей того, что предлагает xAPI.

2) SCORM 2004 4-е издание более строгое. В ссылке на RTE говорится:

Взаимодействие требует числового ответа от ученика. Ответ представляет собой простое число с необязательной десятичной точкой.

Позже говорится:

Если значение символьной строки является числовым диапазоном, оно должно иметь следующий формат, где и оба имеют действительный (10, 7) тип данных.

Таким образом, числовые значения должны быть представлены в наборе real(10, 7), Который упоминается в другом месте как:

Действительный (10,7) тип данных обозначает действительное число с точностью до семи значащих цифр.

(После этого появляется примечание о том, как хранить значения с использованием SQL и что обозначение соответствует ISO 11404)

Поэтому, если вы пытаетесь собрать данные, которые будут использоваться с информационной моделью SCORM 2004, вам следует ограничить использование этим диапазоном значений.

3) До сих пор на рынке я думаю, что мы в основном видели людей, которые захватывают то, что им нужно для разумного захвата, и cmi.interactions используются для простых случаев, но не намного дальше. Я не ожидал бы строгой проверки самого содержимого строк, поскольку LRS обычно предпочитали избегать попыток извлечь из них смысл, и у LRS (с точки зрения строгой спецификации) нет особых оснований для такой проверки. Для последующих систем (таких как СУО и / или инструменты отчетности) лучше обрабатывать данные, которые они распознают, по своему усмотрению.