Representing SCORM Content
The heart of the SCORM content packaging specification is the course’s manifest file. The manifest is an XML file that completely describes the content. It contains several essential pieces:
Resources
Resources are a list of “parts” that make up the course. There are two types of resources, SCOs and Assets.
- An Asset is a collection of one or more files that makes up a logical unit. Assets can either be stand alone units of instruction (“parts” of the course), or they can be logical collections of files that are reused in other parts of the course (a common set of branding images for instance).
- SCOs are units of instruction that are also composed of one or more files. SCOs are almost always instructional parts of a course.
The key difference between a SCO and an Asset is that a SCO can communicate with the LMS, whereas an Asset is simply static content that is presented to the user. Any resource that can be launched by the learner contains a pointer to the page to which the LMS should redirect the learner in order to launch the resource. Resources should also contain a comprehensive list of all the files required for proper functionality of the resource so that they can be ported to new environments and still continue to function.
Organizations
Organizations are logical groupings of the parts of a course (resources) into a hierarchical structure. A single manifest can contain more than one organization of the same content (for instance, to enable the content to be presented differently to different audiences), but typically there is just a single organization, the default organization. Organizations are always structured hierarchically, as a tree. The nodes within this tree are known as “activities” (when referencing them in the context of sequencing) or “items” (when referencing them in the context of content packaging). Any item can have child items nested beneath it. When an item has children, it is referred to as an “aggregation” or “cluster”. Items that do not have any children are required to reference a resource. This resource is what is delivered to the learner when the item is selected. Items that do have children are not allowed to reference resources, they are purely containers for other items. (This can be thought of like the file structure found on a computer… items are either a folder or a file, but not both. Folders may contain other folders or files, but “empty folders” are not permissible.)
More Information:The SCORM 2004 manifest XML format.
Metadata
Every piece of the manifest can be described in detail by associating metadata with it. SCORM metadata is recorded in a well-defined format known as “learning object metadata”, or “LOM”. LOM contains many predefined fields for describing learning content. SCORM also permits the extension of LOM to allow organizations to specify additional metadata. Metadata can be applied to virtually any section of the manifest, for instance it can be applied to the course as a whole, to individual items, or even to individual resources and files to enhance their reusability. Within the manifest file, metadata can either be specified inline within the XML (recommended for small amounts of metadata, especially at the course level), or it can be specified by linking to an external metadata file (recommended for large amounts of detailed metadata). Metadata is typically optional, however SCORM 1.2 does place some restrictions on the minimal subset of data that must be specified if any data is specified. The appropriate amount of SCORM metadata to use will vary widely depending on the intended use of the content, its anticipated longevity, and likelihood that the content will be reused.
More Information: The SCORM 2004 metadata XML format.
Sequencing
In SCORM 2004, every activity can have a set of sequencing rules assigned to it. These rules are encoded in XML in the course manifest. SCORM was designed so that a simple course consisting of nothing but assets should not need to specify any sequencing rules except for the defaults. However, in practice, there are some defaults that should be overridden for all but the simplest of courses.
More Information: The SCORM 2004 sequencing XML binding.
Packaging the Content
Once the content has been represented in XML, it is saved into a file called “imsmanifest.xml”. The manifest file must always exist at the root of the content. To be fully conformant, the content should also include a set of XML schema definition files (.xsd and .dtd files) that formally describe the XML grammar contained within the manifest, including any extensions that may have been used. (Download the SCORM manifest schema definition files). Content can then be delivered either in a simple directory (for instance on a CD), or it can be placed in a ZIP file. When content is put in a ZIP file, it is known as a “package interchange file” or “PIF”. PIFs are far and away the most common SCORM delivery format.
An important principle of content packaging is that ideally, everything needed to deliver the course should be self-contained within the PIF file. SCORM strongly encourages portability and reuse. To maximize these goals, every file needed to deliver the course should be contained within the PIF and listed in the manifest. Furthermore, content developers should avoid the use of server-side code and other dependencies like databases. The use of these tools, as well as external dependencies, is allowed by SCORM, however the industry norm is to avoid them when possible.