In SCORM 1.2, the manifest was mostly structure.
📄 In SCORM 2004, it becomes behavior.
Everything starts with one file:
imsmanifest.xml
It does not just describe your content.
It defines how your course works.
📦 What the Manifest Contains
More Than Just Structure
The SCORM 2004 manifest brings together multiple responsibilities:
- Organization structure
- Activity hierarchy
- Resource definitions
- Sequencing rules
- Metadata
This makes it the central configuration point of the entire package.
It answers multiple questions at once:
- What does the course contain?
- How is it structured?
- How should learners move through it?
🌳 The Organization as an Activity Tree
Structure That Drives Behavior
At the center of the manifest is the
<organization>
element.
This defines your activity tree.
Each
<item>
inside the organization represents an activity, not just a file reference.
This distinction is critical.
- Resources point to actual content files
- Items represent learning activities that can have rules
The hierarchy of items determines:
- Parent and child relationships
- Rollup behavior
- Navigation flow
This is where structure becomes execution.
⚙️ Sequencing Inside the Manifest
Declaring Behavior
Inside each activity (
<item>
), you can define sequencing rules.
This includes:
- Control modes
- Precondition rules
- Postcondition rules
- Rollup rules
- Objectives
These are defined using the SCORM 2004 sequencing XML elements.
This is the key shift:
Behavior is no longer hardcoded in your content.
It is declared in the manifest.
The LMS reads this configuration and executes it.
Your JavaScript does not control progression.
Your manifest does.
🧩 Resources vs Activities
A Common Source of Confusion
One of the most frequent misunderstandings:
Developers confuse resources with activities.
-
<resource>elements define physical files -
<item>elements define logical activities
Sequencing rules apply to items, not resources.
If you attach logic to the wrong layer, nothing behaves as expected.
Understanding this separation is essential for debugging.
⚠️ Why Small XML Errors Break Everything
With this power comes complexity.
Common issues include:
⚠️ Incorrect or missing namespaces
⚠️ Improper nesting of sequencing elements
⚠️ Mismatched identifiers between items and resources
⚠️ Invalid XML structure
SCORM 2004 is strict.
A small mistake in the manifest can:
- Prevent activities from loading
- Break sequencing evaluation
- Cause navigation failures
- Lead to silent LMS errors
Unlike JavaScript, these errors are often harder to debug.
🔍 The Manifest Is Not Static
Another common mistake:
Treating the manifest as static configuration.
In SCORM 2004, it is dynamic logic.
It defines:
- How state is interpreted
- How rules are applied
- How navigation decisions are made
If sequencing is not working, the first place to check is not your API calls.
It is your manifest.
🧭 The Source of Truth
In SCORM 2004:
- The Run-Time Environment provides data
- The Data Model defines state
- The Sequencing engine evaluates rules
But the manifest defines how all of this connects.
It is the blueprint of behavior.
If the blueprint is wrong, everything built on top of it will fail.
SCORM 2004 only becomes predictable when the manifest is treated as the source of truth.
🔢 8 of 12 | SCORM 2004: The Sequencing Era of Learning Standard
