Is The Tin Can API Backward Compatible with SCORM?

Is Tin Can Backward Compatible with SCORM?

Posted 16 July 2012

No, it’s not. And, dude, you’re totally missing the point.

Tin Can is a new paradigm. To make something backward compatible means to live within the constraints of old. The constraints of SCORM have been holding us back for years.

Innovation and progress require change. Embracing Tin Can will require change; change to how we think as well as to how things work. Change is the price of progress.

Some comparisons might be helpful:

Is streaming download backwards compatible with DVDs?
Is the car backwards compatible with horse and buggy?
Is the electric light bulb backwards compatible with candles?

In each case, the newer technology is radically different than the old. The newer technology allows you to do what you did before, but in a much better way. The newer technology requires effort and change to adopt, but the result is a massive improvement in utility. Such is the case with Tin Can.

According to Wikipedia, “a product or technology is backward or downward compatible if it can work with input generated by an older product or technology.” A Tin Can Learning Record Store (LRS) is not required to accept SCORM packages, therefore Tin Can is not backward compatible with SCORM.

But the story doesn’t end there. Just because Tin Can itself isn’t strictly backward compatible doesn’t mean that the products you use are going to abandon backward compatibility. It is possible, and actually quite common, for a product to be backward compatible even though the standard is not.

Your LMS isn’t going to stop playing SCORM content just because it can also accept Tin Can statements. You can still light a room with a candle even though you have a light bulb. You can still play a DVD in your home entertainment system even though you can also use Netflix.

The products that you use will most certainly start to adopt the Tin Can API, but it will be a long time before they stop supporting SCORM. There is too much critical mass behind SCORM for it to go away anytime soon.

I suspect we will see innovative new startups building Tin Can-only products (think Roku, Boxee, Hulu), while existing vendors will incorporate Tin Can functionality into existing products (think Sony, Samsung or Panasonic DVD players with Wi-Fi and “smart apps”).

The point is, that even with the rapid uptake of Tin Can we expect, you won’t need to change what you are doing if it is working for you. If something is broken, or there is something new you want to do, Tin Can will probably be a godsend. If you’re happy with the way things are, you can leave things just the same.

http://twitter.com/krisrockwell Kris Rockwell

Thanks for your points regarding Tin Can and backwards compatibility with SCORM. This is certainly going to be a big issues for developers and I fear that there is already a bit of misinformation on the subject. This clearly sets the record straight and clearly explains why backwards compatibility doesn’t make complete sense. I’m really excited about the specification and hope that the result does extend into the technologies that you have listed. It is my belief that this would create a very feature rich environment for collecting useful metrics that would aid in the understanding of any learning environment.

I’d like to note, perhaps to the benefit of your readers, of the initiative of CMI5 that will address the backwards compatibility with SCORM content. The AICC CMI specification was one of the foundations of SCORM and it is our intention, as stated so long ago, to ensure that CMI5 will work with existing content. I think this is important as it is my opinion that both Tin Can and CMI5 can and will work very nicely together for the future development of content. In my mind, Tin Can provides an excellent pathway to capture complex data from events like simulations. This ideology will work perfect in organizations where complex data capture is needed to work in association with traditional SCORM-style data collection in programs that require both types of measurement to satisfy both regulatory compliance and extensive metric analysis for review of overall training and learning performance. While CMI5 is behind Tin Can in development, I am excited to see where you are taking Tin Can and how the two will work together in the future.

Thanks again for this post. I think it clarifies a lot of confusion, sets the record straight and shows how Tin Can will provide a robust, effective solution for data collection.

Regards,
Kris
http://www.scorm.com Mike Rustici

Thanks for the kind words Kris. I’m anxious to hear how CMI 5 plans to address backward compatibility with SCORM. Will they be doing it at the spec level (requiring all CMI 5 implementations to also implement support for all legacy standards)? Or will they be doing it by providing tools to convert legacy content to the new format?
http://twitter.com/tongrj Richard Tong

How does the Tin Can API compare with IMS Global’s LTI? Also, does Tin Can consider LRMI and LearningRegistry for meta data compatibility?
http://www.scorm.com Mike Rustici

Hi Richard,

How does the Tin Can API compare with IMS Global’s LTI?
The Tin Can API and IMS LTI do different things. LTI is essentially a plug-in infrastructure. It provides a way for an LMS to authenticate into and launch a tool. That tool could often be something that provides a learning experience, but doesn’t necessarily have to be. LTI provides a limited way to for that tool to send results back to the LMS, but at this time, that mechanism only sends a single score value. The focus of LTI is really in the authenticated integration between the LMS and the tool.
The Tin Can API is focused on communicating the results of a learning experience. Whereas LTI communicates just a score, the Tin Can API allows you to communicate a very rich picture of the learner’s activity during the learning experience. Tin Can also includes a mechanism for setting up a trust relationship between an LRS and a tool that provides a learning experience. For this, Tin Can simply relies on OAuth and not its own internal specification.

Does Tin Can consider LRMI and LearningRegistry for meta data compatibility?
The Tin Can API allows for learning experiences to be described in a number of ways. It is metadata agnostic. It will certainly be possible to use LRMI to define an experience and ADL is keenly interested in ensuring compatibility with its learning registry initiative. Tin Can does provide a very simple metadata scheme for a basic description of activities, but it also allows for experiences to be identified with any URI which can have its own associated metadata.

Tin Can API

Is Tin Can Backward Compatible with SCORM?

Tin Can API Email Updates

Tin Can API Email Updates