通常对于 SCORM 2004,您可以使用 imss:sequencing 和 imss:limitConditions。例子:
<imsss:sequencing>
<!-- Optional: Limit attempts (managed by LMS), and or attemptAbsoluteDurationLimit equates to cmi.max_time_allowed -->
<imsss:limitConditions attemptLimit="1" />
<imsss:objectives>
<imsss:primaryObjective satisfiedByMeasure="true">
<!-- equates to cmi.scaled_passing_score of 60% -->
<imsss:minNormalizedMeasure>0.6</imsss:minNormalizedMeasure>
</imsss:primaryObjective>
</imsss:objectives>
</imsss:sequencing>
如果 LMS 不支持这一点,您将不得不将数据放在学生尝试中,但这也很危险。这就是为什么 - 如果学生或 sco 曾经将“cmi.exit”设置为“”、“正常”、“注销”或“超时”,这实际上是尝试的结束。在 SCORM 2004 中,LMS 有责任创建新的尝试,并且您当前的学生数据将被重置。这意味着,您必须设置 cookie 或本地存储值才能可靠地跟踪这一点。但是,由于学生使用其他设备,这甚至无法可靠地工作。所以在某种程度上,这就像我所说的'dicy'。
在 SCORM 1.2 中,LMS 供应商对此的处理方式有所不同。规范并没有非常清楚地说明 LMS 将如何管理模式和状态,如此多的模式和状态以多种方式运行,这使得弄清楚如何对处于“审查”模式做出反应,例如,如果 LMS 允许你更难依赖评分后继续设置值。大多数 LMS 供应商会告诉您管理自己的尝试,甚至可能让您永远进行尝试。我可以继续讨论这个页面,但如果您需要更详细的信息,请告诉我。