SCORM and AICC compared

GerryWaz: Anyone know of a good, dispassionate comparison of the two standards? Strengths and weaknesses of each?

In matters of technology, newer is frequently equated with better. However, while SCORM is the newer specification and is more widely supported, there are valid reasons for using courses and management systems based on the AICC specifications.

Below are some points to consider when deciding between AICC and SCORM. (We consider only SCORM 1.2 and SCORM 2004, since earlier versions of SCORM are effectively obsolete.)

Packaging and deployment

Thanks to SCORM's well-defined packaging model, deploying SCORM courses is often as simple as uploading a zip file. Historically, deploying AICC courses involved more steps due to the lack of a similar packaging model for these courses. In late 2006, AICC published a packaging specification for AICC courses. However, this is still not part of the core AICC specification, so neither AICC-conformant courses nor AICC-conformant LMSs are required to support it. (EKP supports AICC course packages.)

Ease of development

SCORM-conformant courses communicate with an LMS by calling methods of a JavaScript object called the API adapter. AICC-conformant courses communicate with an LMS by sending HTTP messages to the LMS, and interpretting the LMS's responses. (This communication method is known as the HTTP AICC CMI Protocol, or HACP.) Where courses are developed without the aid of specialized course authoring tools, it's usually considerably easier to implement SCORM communication than AICC communication. (However, most specialized course authoring tools shield the developer from these differences.)

Technical requirements

A conformant SCORM API adapter must implement complex rules for validating tracking data and reporting errors and, in the case of SCORM 2004, for evaluating and enforcing sequencing rules and processing navigation requests. Because of this complexity, many robust implementations use Java technology to implement the API adapter, meaning that Java must be available on the user's machine. (Both EKP and ADL's reference implementations use Java to implement the API adapter.) On the other hand, since AICC courses use direct HTTP-based communication, LMSs typically don't require Java to track AICC courses. (However, the courseware itself might still require Java.)

Cross-site scripting

Cross-site scripting occurs when content loaded from one web site in a browser attempts to read or manipulate content loaded from another web site in the same browser. In general, cross-site scripting presents a security risk, and browsers rightly restrict it in most cases. However, these restrictions can also interfere with tracking of courses where the courses reside on a different web site from the LMS. The problem is usually more serious for SCORM courses than for AICC courses. As described above, SCORM courses communicate with the LMS using JavaScript calls, and these are almost always blocked when the course and LMS reside on different sites. On the other hand, due to the nature of AICC communication, AICC courses have greater choice about the specific technology used to perform the communication, and different technologies enforce different policies regarding cross-site communicating. For example, an unsigned Java applet may not communicate with a site other than the one from which it was loaded, but a signed Java applet may do so if the user explicitly grants permission. Even without the use of browser plug-ins such as Java or Flash, an AICC course can implement course-to-LMS communication (but not LMS-to-course communication) simply by using standard HTML forms.

Sequencing

The AICC, SCORM 1.2 and SCORM 2004 specifications all provide sequencing mechanisms—that is, mechanisms for specifying rules concerning the order in which independently trackable units of content can be delivered. (In SCORM terminology, these units of content are called shareable content objects, or SCOs. In AICC terminology, they are known as assignable units, or AUs.) However, only the SCORM 2004 specification requires the LMS to support these mechanisms. On the other hand, it's always possible to implement sequencing in a way that is internal to the SCO or AU. So this is only an issue if you aim to reuse SCOs/AUs at a level of granularity below the course level.

Internationalization

The polite term for the AICC specification's support for internationalization is “boneheaded .” In particular, the AICC specification specifically prohibits the use of Unicode character encodings (e.g. UTF-8, UTF-16), instead requiring the use of one of the ISO 8859 family of encodings. Whereas Unicode encodings support virtually all modern languages, the ISO 8859 encodings support only a very limited set of languages, with Asian languages being particularly poorly supported. (Chinese, Japanese and Korean are all unsupported for example.) There's no good reason for this restriction, and in practice many systems "extend" the AICC specifications to support other encodings. (For example, EKP supports a wide range of encodings beyond the ISO 8859 family, including both UTF-8 and UTF-16.) However, a further problem is that the AICC mechanisms provide no clear way to specify which encoding is being used, so trial and error is often necessary in order to ensure non-English text displays as intended.