CMI data model thoughts

[jpcampbell]

As a user of the CMI data model through SCORM, I jotted down my
thoughts a number of months ago. Much of this may be out of scope,
but I wanted to share some of the things I felt were important from my
perspective. Whether or not they can be addressed with this
harmonization is up for debate, but maybe this can provide additional
context regarding the user base by which these standards and concepts
get used.

The original doc is here:
https://docs.google.com/Doc?docid=0AaZ2XUMnHKZMZDg5YmhzNV8zNTZjOGZ0djZjcg&hl=en&authkey=CLeynP0F

Pasted below...

* Add a cmi.attempt_count element so that content can access the
attempt count of an activity

* Add the ability to access runtime data for prior attempts of
activities: eg. cmi.attempt.n.success_status, etc.

* Add shared state across SCOs (maybe 4th Edition adl.data)

* Bring in ADL SCORM 2004 4th Ed. extensions to the data model
(extended objectives info, data buckets, ...)

*Enhance cmi.interactions
* learner_response and correct_responses are a short (URL) type.
I think this portion needs to be reworked. It's important to have
free form descriptions of the responses available in the interaction
data for reporting. We need some kind of list of possible responses
(longer string type) with an ID and description. Then the IDs can be
used in the correct and learner response fields.

* Refresh the data model elements of cmi.interactions with
reporting in mind.

* Clarify and rethink what cmi.interactions.n.objectives are how
they should be used.
* Add a real link between them and cmi.objectives
* Increase SPM, as 250 per activity is not sufficient. Would need
to discuss the actual amount needed.

* Clarify persistence. The effectiveness of the data captured in
cmi.* is weakened by the fact that there are no long-term persistency
requirements. This has added quite a bit of confusion in the
community. For example, many organizations think cmi.interaction data
is guaranteed to be persistent and accessible and have tied key
requirements to this false notion. This may be due to the unclear
notion of journaling vs. state.

* Find ways to require/encourage better reporting and extraction of
cmi data? In many cases there is no way to retrieve this data after
the fact. This may be compliant, but lacks utility. "Require" may be
out of scope, but ensuring the data model captures useful data for
reporting may not be.

thanks,

jpc