Just like any technology, SCORM has evolved through the years. There are currently four different implementable versions of SCORM. SCORM 2004 has several different editions, and the latest version/next generation of SCORM is the Tin Can API (aka Experience API or xAPI.) Furthermore, SCORM isn’t the only e-learning standard out there. Other standards like AICC HACP and IMS Common Cartridge have their place in the industry. This page will describe these common e-learning standards and provide recommendations about adoption of each. The chart below summarizes the comparison of each standard:
|Release Date||Pages||Widely Used||Run-Time||Packaging||Metadata||Sequencing||Works Cross Domain|
|AICC HACP||Feb 1998||337||Yes||Yes||Yes||No||No||Yes|
|SCORM 1.0||Jan 2000||219||No||Yes||Yes||Yes||No||No|
|SCORM 1.1||Jan 2001||233||No||Yes||Yes||Yes||No||No|
|SCORM 1.2||Oct 2001||524||Yes||Yes||Yes||Yes||No||No|
|SCORM 2004 “1st Edition”||Jan 2004||1,027||No||Yes||Yes||Yes||Yes||No|
|SCORM 2004 2nd Edition||Jul 2004||1,219||Yes||Yes||Yes||Yes||Yes||No|
|SCORM 2004 3rd Edition||Oct 2006||1137||Yes||Yes||Yes||Yes||Yes||No|
|SCORM 2004 4th Edition||Mar 2009||1162||Yes||Yes||Yes||Yes||Yes||No|
|IMS Common Cartridge||Oct 2008||135||No||No||Yes||Yes||No||Yes|
|IMS LTI||May 2010||25||In Academic LMSs||Yes||No||No||No||Yes|
|Tin Can API
|April 26, 2013||85||Not Yet||Yes||Partial||No||No||Yes|
Released January 2000
SCORM 1.0 was a draft outline of the SCORM framework. This document did not contain a fully implementable specification, but instead contained a preview of the work to come. SCORM 1.0 contained the core elements that would become the foundation of SCORM. In particular, it specified how content should be packaged (content packaging), how content should communicate with an LMS (run-time) and how content should be described (metadata). Each of these areas was described in a separate specification or a “book of SCORM.”
Released January 2001
SCORM 1.1 was the first real and implementable version of SCORM. It fleshed out SCORM 1.0 into an implementable specification and commercial vendors began to adopt it. These early adoptions revealed that the SCORM idea was valid, but that it left many details to be worked out to be sufficiently robust for widespread implementation.
Released October 2001
SCORM 1.2 is when SCORM hit the big time. SCORM 1.2 incorporated all of the lessons learned from the early adoptions of SCORM 1.1 to create a robust and implementable specification. Vendors who adopted SCORM 1.2 realized dramatic cost savings from increased content interoperability.
Recommendation: SCORM 1.2 was VERY widely adopted and is still the industry workhorse. Every e-learning vendor should make their products compatible with SCORM 1.2. SCORM 1.2 will be around for a long time to come.
Released January 2004
Widespread adoption of SCORM 1.2 brought some problems to light. SCORM 1.2 was very good, but it still had some ambiguities that needed to be tightened up. SCORM 1.2 also lacked a sequencing and navigation specification that allowed the content vendor to specify how the learner was allowed to progress between SCOs. The lack of a sequencing specification meant that most SCORM 1.2 content was produced as a single monolithic SCO instead of created with granular, reusable SCOs. SCORM 2004 addressed both of these problems.
SCORM 2004 (in all its flavors) includes very mature versions of the content packaging, run-time and metadata books. The parts of SCORM 2004 that were derived from SCORM 1.2 are VERY mature and VERY stable. In fact, the individual standards that make up these books are well on their way to becoming accredited standards.
SCORM 2004 also added a new “book” called “Sequencing and Navigation.” This specification allows content vendors to create rules about how users may navigate between SCOs. For instance, a content author can say that “a learner can’t take a final test until he has completed all of the courseware material.” Or, “if a learner fails question X, remediate him back to SCO Y.”
The term “SCORM 2004″ is generally used to refer to any edition of the SCORM 2004 specification. You may also see references to SCORM 1.3. Prior to its formal release, SCORM 2004 was indeed called SCORM 1.3, but that name is no longer in official use. The term “1st Edition” is in quotes in this section because this specification wasn’t actually called “1st Edition,” at the time, it was simply referred to as “SCORM 2004.”
Recommendation: The sequencing specification in the first release of SCORM 2004 had some fundamental problems and wasn’t fully implementable. The “1st Edition” of SCORM 2004 isn’t deployed or usable.
Released July 2004
As industry started to adopt SCORM 2004, it was quickly realized that there were some defects that had to be resolved. ADL quickly responded by issuing SCORM 2004 2nd Edition. This specification was adopted and implementations started to pop up.
Recommendation: SCORM 2004 2nd Edition has significant adoption, but it has not yet reached adoption levels near those of SCORM 1.2. While the core SCORM books are very stable in all of SCORM 2004, sequencing is a VERY complicated specification. Vendors creating new product implementations should strive to include support for SCORM 2004.
Released October 2006
The complications of the sequencing and navigation specification have mostly driven the future evolution of SCORM. Third Edition is largely a set of improvements to the sequencing specification to remove ambiguities and tighten the specification for greater interoperability. The big change in Third Edition was the addition of user interface requirements for LMSs. Previously, it was completely up to the LMS to determine the appropriate user interface. In Third Edition, new language was added that requires the LMS to provide certain user interface elements to enable sequencing and navigation to function consistently across systems.
Recommendation: SCORM 2004 3rd Edition, like 2nd Edition, has significant adoption and vendors should strive to support it. Of all SCORM 2004 editions, the 3rd edition is the most widely used.
This edition contains further disambiguation of the sequencing specification and also adds a few new features to the sequencing specification which will broaden the options available to content authors. The new features in Fourth Edition make creating sequenced content much simpler. ADL is unveiling a new certification process for SCORM 2004 4th Edition which will require LMS’s to be continually retested to maintain their certification ensuring that compliance problems can be continually addressed.
Recommendation: The new features of SCORM 2004 4th edition increase its usefulness dramatically, and we recommend you adopt it. SCORM 2004 4th Edition should be supported by vendors supporting SCORM 2004.
Released February 1998
SCORM is a “reference model.” The individual books of SCORM are actually each references to other specifications. Some of the most significant contributions to SCORM came from the AICC. The AICC was an early pioneer in the world of e-learning standards; their specifications date back to 1980s and the days of “computer-based training.” AICC’s “CMI Guidelines for Interoperability” was the first widely adopted specification for interoperability between e-learning content and LMSs (Document No. CMI001 on the AICC site).
The run-time communication in SCORM was based on the AICC’s work. Originally this specification began with file-based exchange of data between content and LMSs. It was then updated to support an HTTP-based data exchange. Recently, it was updated to support an EMCAScript-based data exchange to harmonize with SCORM. AICC HACP is still widely supported, mostly using the HTTP-based data exchange (known as HACP, “HTTP-based AICC/CMI Protocol”). AICC publishes many specifications, but when somebody refers to the “AICC spec,” they are most likely referring to to HACP protocol in the AICC CMI specification.
The HACP protocol has a unique characteristic that makes AICC HACP very useful and, in fact, preferable to SCORM in certain situations. Specifically, since HACP is HTTP-based, it doesn’t suffer from the cross domain scripting problem that plagues SCORM’s ECMAScript-based communication. In SCORM, because of (good and intentional) browser security restrictions, content served from one domain (ex. www.mycontent.com) can’t talk to an LMS that is served from a different domain (ex. www.mylms.com). In AICC HACP, that problem is less restrictive, making it a useful alternative to SCORM in certain deployment situations.
Recommendation: AICC HACP should be supported by most vendors. Its level of adoption is likely still second only to SCORM 1.2.
Released October 2008
Another organization that significantly contributed to the books of SCORM is IMS. IMS’s content packaging and sequencing specifications are the origins for two of the books of SCORM. Like AICC, IMS produces many specifications.
Recently IMS released a specification known as Common Cartridge that has some overlap with SCORM. Unfortunately, relations between IMS and ADL have soured because of a disagreement over intellectual property. IMS is now positioning Common Cartidge as a competitor to SCORM and some have even called it a “SCORM killer.” Our assessment is that Common Cartridge and SCORM solve two different problems and serve two different industries. Assuming Common Cartridge is adopted, the two specifications will likely live side by side.
Common Cartridge is designed to serve the higher education market, while SCORM primarily serves the online training market. Common Cartridge includes things that are appropriate to classroom-based education, such as discussion board topics and question banks. It lacks certain concepts that are more appropriate to online training like run-time data communication and sequencing.
Recommendation: It is still too early to tell whether the industry will adopt Common Cartridge widely. We recommend considering it if you are targeting education-based clients.
Released April 26, 2013
The Tin Can API is the newest version of SCORM and it solves a lot of issues that were inherent with older versions of SCORM. Mobile learning, team-based learning, cross domain functionality, sequencing, removal of the need for a web browser, and simulations/serious games are just a few things that are now relatively easy to accomplish.
The Tin Can API removes content from the LMS, and allows the content to send “statements” based around [actor] [verb] [object], or “I – did – this” to a Learning Record Store (LRS). LRSs can live on their own or as part of an LMS. There are a lot of good things happening with the Tin Can API — go read about them.
Recommendation: Next-gen SCORM with the Tin Can API is ready for adoption, and is highly recommended. We expect it to be the de facto specification for e-learning for a long time to come.
Release date TBD
CMI-5 is an emerging spec from AICC, designed as a successor to HACP. Its big improvements include the ability to submit results as binary documents (PDF, images, videos, etc), submitting arbitrary key/value data pairs and a SOAP binding for data exchange. CMI-5 is still in draft form and not yet ready for implementation
Recommendation: Hold off on implementation until an implementable version is released. The new functionality of CMI-5 is a subset of what is available in the Tin Can API. There is currently work being done to see if there is value in the two specifications working together.
Traditionally, publishing content to an LMS could take a dozen or more manual steps for the end user. PENS is an eLearning standard that addresses the publishing of content from an authoring tool to an LMS. PENS offers one-click publishing, simplifying the process, and removing another layer of friction between content creators and LMS’s. It doesn’t replace other eLearning standards, but works in conjunction with them.
Recommendation: PENS is supported in the latest release of SCORM Engine, and SCORM Cloud can accept PENS requests. We plan to add support to SCORM Driver in the future. We recommend considering PENS if you deal regularly with importing lots of content to an LMS, and/or if that import process is tedious and time consuming.
ADL would ultimately like to transfer stewardship of SCORM to a non-governmental organization. Just like the government developed the Internet, GPS and a myriad of other technologies which have been spun off for the world to evolve and enjoy, ADL would like to give control of SCORM to the community. A few years ago, an organization called LETSI was formed to be the community’s steward of SCORM. Unfortunately, the lawyers got involved and the stewardship process has been put on indefinite hold. LETSI is still active however and developing tools to move the e-learning industry forward with an agile and innovative approach. LETSI is a completely open and transparent organization and all are welcome.
LETSI RTWS (run-time web services) is an enhancement to SCORM. Consider it the stopgap between traditional SCORM and whatever SCORM 2.0 will be. Building on the existing standard, it brings new features, fixes for old problems, and new ways for e-learning companies to do business. RTWS is great for offline learning, games, simulators, mobile devices, and adding an extra layer of security.
Recommendation: RTWS is supported in the latest release of SCORM Engine, and SCORM Cloud can accept RTWS content. We plan to add support to SCORM Driver in the future. RTWS is an ideal solution if you’re looking to take e-learning out of the browser and into simulations, games, or on mobile devices. RTWS is also recommended if you need extra security for higher-stakes e-learning.
LTI (Learning Tools Interoperability) is mostly used by LMSs serving in educational settings. It’s a little different from other e-learning standards — it’s a plug-in architecture that allows LMSs to work with third-party/remote learning tools. It provides the ability to authenticate LMS users into the remote tool via OAuth. Simple Outcomes (part of LTI) allows the remote tool to report a score back to the LMS. This is the only LMS tracking that is available in LTI.
Recommendation: LTI is used commonly in the world of education, so if you intend to work in that space then LTI is something you should strongly consider supporting. LTI is supported in SCORM Cloud as a way to deliver a Dispatch — it allows a LTI conformant LMS to play SCORM content. The Simple Outcome (score) is delivered to the LMS, but you can still track SCORM data in SCORM Cloud.
Our products support the applicable standards to achieve the maximum possible interoperability. If you have limited resources though, we recommend adopting the standards in the following order of priority:
Yes. There are a lot of versions and editions floating around, but the fundamentals have remained very consistent through each release. Adopting SCORM does require continued vigilance to ensure you remain up to date (as is the case with any technology), but the core technology is stable, workable and beneficial.
The editions of SCORM 2004 are largely backwards compatible, however the versions of SCORM are not. Tools are available to assist with migration between SCORM versions and most e-learning products should be able to support all versions/editions side-by-side without any significant difficulty.