But I agree totally about creating a much simpler packaging spec. It’s what I argue here: http://www.learningconversations.co.uk/main/index.php/2008/08/08/scorm-warning

However, one of the main problems with SCORM is it’s just not rich enough… It’s only about delivering and tracking content. What happens to the learner interactions, the forum posts, the wiki entries, the shared bookmarks? None of that gets moved across.

My vote is to document and use the already open standard which is the Moodle backup format (XML containing all the database entries + course files all contained in a single zip file). This format should be rich enough for most LMS’s to interpret.

I would like to see a tiered / abstracted protocol for the API. It’s nice, but unnecessary and counterproductive (when LMS vendors each support a different flavor of the implementation), to have control over the value of cmi.completion_status from the content. Why am I dealing with this string based logic from the content? How many fairly common methods am I having to set up a rube-goldberg chain to set? And how often is the LMS going to want to hear something only slightly different?

How about a common set of Wrapper > LMS API calls for a simple protocol tier. These could be delegates for more sophisticated classes or the simplest base classes for more sophisticated functionality.

setComplete(bool);
//toggles the completion of the SCO to the boolean value - let the LMS sort out how it’s going to set the completion_status variable since it knows what it wants anyway.

setScore(int);
//sets the score for the package

Anyway - you get the point. If we have a simple set of methods to work with that abstract as much of the functionality and sophistication away from the typical developer we’ll be doing a service to everyone. Frankly, some of the things we are trying to do really belong on the LMS end, IMO (the completion_status string setting is one example.) Imagine having 6 common simple calls… It’s more friendly than some of the relative complexities with current standard packaging practices (I know, i know… we have some control over that as developers by customizing our API Wrapper and framework — still…)

The biggest problem I have with the current standard packaging is the promise of reuse and sharability — not many are sharing content or reusing. I think we’ve focused on the manifest as the primary defining mechanism and we have ended up with monolithic packages, often with content that is compiled in places where it needn’t be (Flash). This makes the content largely non-reusable. This ISN’T SCORM’s fault… But it is a function of the focus of the standards. We have followed a pattern that has been built up by tool vendors…

More in a few - gotta jam.

This is true for a number of reasons, most of which LETSI (and ADL in the past) could not control. When the documentation is finally completed (which takes alot of testing and reviewing) you have to wait for the system vendors to hit an “update” point in their software lifecycle. If SCORM 2.0 were released on Monday, and a vendor had just released a new version of their system on Saturday, they wouldn’t begin working SCORM 2.0 on Monday they’d wait until Thursday or Friday (maybe even Thursday or Friday two weeks from now). And, just like the documentation taking multiple test and review cycles, each vendor also needs those test and review cycles to ensure their product meets the specified requirements. And, let’s remember that each system vendor is on a different software lifecycle. SO…. In the interim, a “scorced earth policy” would mean destroying all of the systems and content that currently work.

Is any of this ideal or perfect? No, but welcome to the world of specifications and standards.

LETSI looks forward to seeing a white paper with your ideas for technical solutions, and we’d welcome any concrete recommendations for how to make this process faster and easier!