Thanks for your response, I better understand what you want to say. So, content developers should create another organization like LETSI to create the CCCP !

Your comment “I would advocate for focusing on interoperability and reduce the scope of Scorm 2.0 to a communication protocole so the content developers are able to create the content the way they want” is precisely the issue: many developers don’t care about aggregation. The problem is that aggregation is at the heart of SCORM.

The original concept of SCORM was to turn bits of electronic media (content) into shareable objects that could be imported into any course (SCOs: shareable content objects). To achieve this objective, SCORM’s creators decided to use existing standards where feasible (ECMAScript, IMS manifest, cmi data model) and write new standards where needed (sequencing and navigation). This collection of standards is the RM of SCORM: Reference Model.

Over the years, SCORM has been deemed a success largely because of the void it filled in terms of standardizing course interoperability — in spite of its mission of supporting content aggregation.

Although interoperability is all most developers use SCORM for, it’s SCORM’s primary mission. It wouldn’t be fair to convert SCORM into a simple communication protocol. However, I think it would be completely reasonable to extract the communication protocol element of SCORM and use it to create a new standard for communication/basic interoperability.

SCORM will always need a communication standard for course-SCO communication; this new standard could be folded into SCORM as a supporting element, just like the cmi data model or IMS manifest.

Does SCORM need to be responsible for creating and maintaining that communication standard? I don’t think so, as it ultimately distracts from the primary goal of SCORM: enable developers to reuse content through aggregation.

If communication/interoperability is split into a new standard, most developers could simply use that new standard and wipe their hands of SCORM. The pro-aggregators could then intensify their work on aggregation and related issues, making SCORM a stronger standard.

Strangely I feel the contrary, it seems to me that there a huge demand for the second option, although this demand has not been really envisaged by the LETSI for white papers submissions.

Before reading you’re post, I was somewhat divided on how to meet the needs of both parties.

“All kidding aside, I do believe we should consider removing the burden of the communication protocols from the SCORM 2.0 workgroup and let the discussions about SCORM 2.0 focus on aggregation”

I’m not sure to understand what you want to say. Basing on what you’ve written, I would advocate for focusing on interoperability and reduce the scope of Scorm 2.0 to a communication protocole so the content developers are able to create the content the way they want ?

Regards,

Goulwen