Last time, I looked at the Meta-Data section of the SCORM 1.2 CAM specification and decided to ignore it (for now, at least). In this post, I’m going to start to look at the Content Packaging section of the CAM specification. This defines:
- The format of a “manifest” file which describes the content of the package; and
- Directions for creating the electronic package of files – typically as a zip file – so that they can be transferred from place to place.
It starts out by defining the content structure which can be considered to be the map that’s used to organize the resources that are included in the package. However, the specification makes the important point that the content structure doesn’t define the LMS functionality. So, for the purposes of this project, I’m going to have to understand how the content is structured in order to read a package, but I’m free to store the learning content in whatever way I want once it’s loaded into my “imaginary” LMS.
The specification goes on to say that the content structure is described by 3 things:
- The content hierarchy – a tree-based “table of contents” – so to speak.
- Meta-Data – data describing the contents of the package.
- Sequencing and navigation instructions.
The first of these should be fairly straightforward to understand. I’ve already decided to ignore the Meta Data for now since it doesn’t appear to be a mandatory feature. The sequencing and navigation instructions will require further investigation as I go along.
The SCORM 1.2 content hierarchy is based on the idea of ‘organizations’ and ‘items’ (see figure above) where an item can be:
- A collection of other items (akin to a folder in Windows, or a directory in Linux/UNIX); or
- A file such as a SCO, a GIF file, a Flash file …. known, in SCORM terms, as ‘assets’.
In a content package, the content hierarchy is described in the ‘manifest’ file which is a mandatory part of the package. This is an XML file that contains the description of the content hierarchy, a list of resources included in the package, and meta-data about the resources.
So far, no great surprises. Next time – I’m going to look at how a typical manifest file is constructed.