SCORM package example: a minimal one

What does every SCORM package contain?

A minimal SCORM package example is a zip with two things: an imsmanifest.xml file at the root, and one HTML file the manifest names as the launch page. That HTML finds the LMS API, initialises, writes a status, commits and finishes. Everything else in a real course is content layered on that skeleton.

It helps to see the skeleton on its own, because most broken packages are broken at this level rather than in the content. If the manifest is in the wrong place, the LMS rejects the upload. If the launch page never talks to the API, the course plays perfectly and records nothing. Getting the two-file version right first makes every later problem easier to locate.

The manifest at the zip root

The single most common reason an LMS refuses a package is that imsmanifest.xml is not at the top level of the zip. It happens when someone right-clicks a folder and compresses the folder itself, so the zip contains my-course/imsmanifest.xml instead of imsmanifest.xml. The LMS opens the zip, does not find the manifest where the specification says it must be, and reports the package as invalid.

The fix is to select the files inside the folder and compress those. When you open the finished zip, the first thing you see should be the manifest, not a folder.

The manifest does three jobs: it says which SCORM version the package uses, it lists the course structure (the organisation and its items), and it points each launchable item at a resource with an href to the file the LMS should open. Every element is explained in imsmanifest.xml explained.

A two-file SCORM 1.2 example

Here is the smallest manifest that declares one launchable item, a sharable content object (SCO) in SCORM terms:

<?xml version="1.0" encoding="UTF-8"?>
<manifest identifier="com.example.minimal" version="1.0"
  xmlns="http://www.imsproject.org/xsd/imscp_rootv1p1p2"
  xmlns:adlcp="http://www.adlnet.org/xsd/adlcp_rootv1p2">
  <metadata>
    <schema>ADL SCORM</schema>
    <schemaversion>1.2</schemaversion>
  </metadata>
  <organizations default="org1">
    <organization identifier="org1">
      <title>Minimal course</title>
      <item identifier="item1" identifierref="res1">
        <title>Lesson 1</title>
      </item>
    </organization>
  </organizations>
  <resources>
    <resource identifier="res1" type="webcontent"
      adlcp:scormtype="sco" href="index.html">
      <file href="index.html"/>
    </resource>
  </resources>
</manifest>

And a launch page that does the minimum an LMS needs to record a completion:

<script>
function findAPI(w) {
  var n = 0;
  while (!w.API && w.parent && w.parent !== w && n++ < 10) { w = w.parent; }
  return w.API || (window.opener && window.opener.API) || null;
}
var api = findAPI(window);
if (api && api.LMSInitialize("") === "true") {
  api.LMSSetValue("cmi.core.lesson_status", "completed");
  api.LMSCommit("");
  api.LMSFinish("");
}
</script>

Zip those two files, with the manifest at the root, and you have a valid SCORM 1.2 package. It launches, initialises, marks itself completed, saves and closes the session. A real course does the same four things with more steps in between and more data written, such as score, bookmark and time. The item-and-resource relationship is described in what is a SCO.

What an authoring tool export looks like

Open a package exported from any mainstream authoring tool and the same skeleton is there, surrounded by much more:

imsmanifest.xml
*.xsd               (schema files the manifest references)
index_lms.html      (launch page named in the manifest)
scormdriver/ or lms/  (the tool's own API wrapper)
story_content/ or assets/  (slides, media, fonts)
data/               (quiz definitions, text, settings)

The names vary by tool, but the roles do not. There is always one manifest at the root, one launch file per SCO, a block of JavaScript that handles the API calls, and the course content itself. The schema definition files (.xsd) are often included so the manifest can be validated against them; strict validators expect them to be present.

Where can you find sample packages?

When you need a package to test an LMS rather than build a course, you do not have to make one. ADL, the organisation behind SCORM, has published sample and test content alongside the specifications, and Rustici Software publishes a set of free sample packages on scorm.com covering SCORM 1.2 and the SCORM 2004 editions. Many LMS vendors and community forums also share small test courses. Treat any sample as a fixture for testing, not as a template to ship.

A sample package is most useful when it exercises the feature you are investigating: a single-SCO 1.2 package for basic completion, a multi-SCO 2004 package for sequencing, or one that writes interactions if you are testing quiz reporting.

How to check a sample really works

Do not trust a sample package, or your own, because it opened. Check it:

1. Open the zip and confirm imsmanifest.xml is at the root.
2. Confirm the resource href points to a file that exists in the zip, with the same capitalisation.
3. Launch it and watch the runtime calls: one initialise returning "true", the status write, a commit, and a finish.
4. Close it, relaunch, and check the LMS kept the status.

That last step catches more problems than the first three combined. A fuller pre-upload routine is in how to test a SCORM package before the LMS does.

Where SCORM Central fits

SCORM Central converts files you already have — PDF, PowerPoint, Word, or video — into SCORM 1.2, SCORM 2004, cmi5, or xAPI, and shows you the manifest, the full runtime log, and a conformance report on every build, so you can see exactly what a package will report before an LMS does. See how it works, or start with one file.