SCORM 2004 Content Aggregation Model

This will give you a general overview of what a SCORM CAM can accomplish. Note: You may also hear this called a "PIF" a Package Interchange File. Though its not necessarily meant to be manually created, you can do this with some basic tools.

• A zipping tool (commonly built into the operating system). Tip: Some LMS's are lets say temperamental about the format of the zip. Hidden files like .DS_Store, .svn, .git etc.. can some times cause the package to invalidate. I have a SCOZipper tool for OS X (Mac) linked back on the Wiki Home page.
• A text editor like notepad, text edit, or something more advanced like Ultraedit, Oxygen, or Aptana Studio for editing the XML manifest.

A CAM is the mechanism of delivering a content package to a Learning Management Server that supports SCORM 2004. It uses a manifest of information about that package called an imsmanifest.xml. These include the sequence and navigation describing the organization of your content, resources they use, along with optional parameters to help better control the behaviors of your content.

Along with the manifest, are all the schemas that validate the markup and metadata. These are required to be found in the root of your package. It would have been nice if they were in there own folder, but unfortunately the result ends up looking like what you see.

This entire package needs to be self-contained. Do not zip the parent folder that houses these files. If you do, the package may fail to import due to the LMS being unable to locate the imsmanifest.xml in a sub folder of your package.

You will notice a folder called “content”. This is the only folder in that entire package that I placed in this directory. It contains the Shareable Content Object(s) I plan to bundle with this package. You can place the files directly in the root of the package, but for organizational purposes I recommend you place the content in a folder that makes sense so you don’t cross-contaminate with all the files required by the CAM. So to recap – all the other files in this package are required by the CAM to ensure a successful and compatible import.

Designing your delivery

The scope of a manifest is suppose to be something that can stand on its own or apart of a course, or convey many courses. Problem is, there are issues with trying to actually push a very large CAM. The specification has been stated that there was no consensus on how to push a huge course because of the methods repositories use to store content. Essentially, we also have a problem because we need to use either FTP or HTTP to transfer these large packages. But, do you even need to bundle your content into a CAM/PIF? The imsmanifest.xml leaves you the ability to point back to a fully qualified URL which could be where you host the content, like a content repository. Course, if you have security wrapped around that, you'll have some other hurdles to get around.

Manifest: imsmanifest.xml

This file has a series of mandatory and optional contents. This depends greatly on how simple or complex your package is. Think of it as structured inventory or something that allows you to define a table of contents. XML like HTML is a tag based system to convey structure. You’re required to open “tag” and close “tag” like <tag identifier=”001”></tag>. There are Attributes in tags, which are also called nodes or elements. If you don’t close a tag or quotes or typo tag names, the result will be an invalid markup which will fail to import. You can use advanced tools I listed above to keep this from happening. You can also launch the XML in Internet Explorer, FireFox, Chrome, or Safari to see if it loads properly if you don’t use these tools.

Mandatory parameters with some optional values to consider:

Note: Please open the imsmanifest.xml to review the XML Formatting. I will use bullet points here to keep from trying to write markup in my document.

• Manifest
  • Identifier – This identifies the manifest and is unique within the manifest. I’ve often been asked if it has to be globally unique, and based on everything I’ve read, its only unique within the manifest itself. Identifiers are normally handed out by systems so if your doing this by hand, take care in making sure you don’t duplicate any identifiers in your entire package. Identifiers do not contain spaces.
  • Version – You can increment your version as you release the CAM to distinguish between manifests with the same identifier. Think of this like software releases ..1.0, 1.1, 2.0 etc… This has a max character value of 20.
  • Metadata
    • Schema – “ADL SCORM” : This will rarely change.
    • SchemaVersion – “2004 3rd Edition” : This will rarely change, unless you plan to publish in 4th edition. This depends greatly on the LMS Support for SCORM Editions.
  • Organizations
    • Default – Points to your default organization identifier
    • Organization
      • Identifier – Unique ID within the manifest. When manualy doing this, I typically follow a ORG-000, ORG-001 type naming convention so its more easily read. ORG = organization.
      • Adlseq:objectiveGHlobalToSystem (optional) : defaults to true
      • Title – This is a 200 character limit value for the title of this tier in your organization.
        • Item – This element can be nested and many levels. This is typically based on the structure of your TOC (table of contents) and can appear within your structure 0 or more times. Essentially – if you have 1 or many SCO’s at this level, you could add them here.
          • Identifier – You could use your own internal SCO ID for this level, or something like ACT-000, ACT-001 etc …
          • Identifierref – This will point to the resource identifier for this item (SCO).
          • Isvisible (optional) defaults to true, you could hide it from the structure by setting it to false.
          • Parameters (optional) “?name=value&state=WA” - format to push parameters into the launching file of the SCO, limit 1000. Passed a theme, grade or other values into the content this way to extend the behavior of a SCO to look or function different when desired. “&” is an entity used as a ampersand. If just a “&” was used, it would break the XML Markup.
          • Structure (optional) : defaults to hierarchical, limit 200
          • Adlseq:objectiveGlobalToSystem (optional) : defaults to true
          • Title – This is a 200 character limit value for the title of your SCO.
          • Advanced optional values at this level also include the ability to specify Launch Data, set a completion threshold, scaled passing score, time limit, time limit action and attempt limit. I will make note of these later in another section.
  • Resources
    • Resource
      • Identifier – Unique ID. I typically use RES-000, RES-001 etc …
      • Type – webcontent (I haven’t found another setting for this)
      • Adlcp:scormType – sco (or asset if your setting up shared dependancies *See comment below about shared assets)
      • Xml:base – (Optional) but this allows you to specify your folder like “content/QUnit_Tests/” so you don’t have to keep re-entering it per file below. Keep in mind all these could be stored on a media server so this could be a fully qualified URL to that media server which means you wouldn’t have to include the SCO’s in your CAM package. Just the imsmanifest.xml. (food for thought)
      • Href – typically index.html, player.html or whatever your launching file is for the SCO.
      • Dependency – element (optional)
      • Identifierref – “common_files” or the name of your shared asset resource
      • File – element x (number of files used by SCO)
      • Href – index.html

Shared Assets/Resources

This typically would be managed by a system, but you can do this manually. You may have a case where several SCO’s are using the same core files like Cascading Style Sheets (CSS), JavaScript (JS) or even Hyper Text Markup Language (HTML). They may even share audio files, images, video’s or beyond. This commonly saves the end-user bandwidth by allowing each SCO to pull from an asset pool you include with your CAM Package. This can save file size on your CAM Package to boot. The following has to be accomplished to take advantage of this –

• Evaluate shared files between all SCO’s in your package
• Adjust index/player.html file paths to go back a directory to locate their assets from the shared location since they will no longer be relative to the launching file. This is accomplished by doing a “../” to go backwards in a directory tree. Example: html <script src=”js/jquery-1.8.3.min.js”> now becomes html <script src=”../shared/js/jquery-1.8.3.min.js”>
• Consider making sweeping changes to the design of your SCO(s) by including a base path or domain variable to add to all your file paths. This could even come from launch parameters (above). Or hard code it. It all depends on your needs.
• Consider at an Authoring level, designating a shared/common asset vs. one that is local. Possibly even having to promote a file to ‘shared’ and adjusting it for all SCO’s that used it by CAM package.

Advanced Optional Values

Every item within the manifest can have a series of parameters added to increase your control over how they behave.

1. Launch Data – they called this “adlcp:dataFromLMS” within the manifest. This allows you to pass in (much like parameters) a name=value pairs considered Query String. You can use this to change the behavior of the SCO as long as the SCO is hooked to actually read the values your making available. You will need to get with your SCO Developer(s) to document what these parameters are.
2. Completion Threshold – You can specify in a decimal / percentage form (0-1) on how much content the student needs to view to be considered “complete”. Example: you set it to 0.9 so the student will either need to complete 90% of there objectives or view 90% of the pages depending on how the SCO is tooled to be “completed”. Beware: this allows the LMS to manage completion of your SCO's cmi.progress_measure value.
3. Scaled Passing Score – You can specify in a decimal / percentage from (0 – 1) how the student has to do to “pass”. Example: you specify 0.6 so the student will need to score 60% or higher to be considered “passed”.
4. Limit Conditions – You can specify how many times the student can view the SCO by setting an “attemptLimit”. This attempt limit is managed by the LMS. Also you can set an “attemptAbsoluteDurationLimit” in the PTHMS time format for how long the student has to complete the SCO. This is managed by the SCO. So you will need to verify that the LMS supports the attempt limit parameter, and that the SCO your attempting to place a time limit on, actually has the timer implemented. Else, these may just be suggestions.
5. Flow Control - You can specify whether or not the SCO is allowed to auto-advance to the next SCO, and or if you want to limit there movement forward only or even their ability to choose.

Examples

Sequence & Navigation: Prerequisite Example with status and scoring