SCORM Shareable Content Objects (SCOs)

A Shareable Content Object (SCO) is a launchable learning object (resource) that communicates with the run-time environment that launched it. A SCO must be designed so that it can be launched in a standalone web window or in a frame in an HTML frameset.

A SCO is special, because, when launched for a learner in the learner's web browser, it will communicate information back to the LMS that launched it, often a remote server. This communication allows the LMS to track information pertaining to the learner's experience.

A SCO represents the lowest level of granularity of a learning resource that an LMS should track. SCORM does not impose any particular constraints on the size of a SCO. A SCO can be a single web page or a collection of web pages (as long as the collection of pages can be considered a self-contained single unit).

Each SCO should be reusable and independent of its learning context. To achieve such reuse, a SCO should be "self-contained" and not reference or link to other SCOs.

Launched SCOs may be launched in a browser frame or a popup window. A SCO should not close the window they are launched in, unless it determines it "owns" the window.

Any "passive" asset can be converted to a SCO by declaring it as a SCO in the manifest file and ensuring it exhibits required SCO behaviors.

    Required SCO run-time behaviors:
  • Find the RTE API instance provided by the LMS
  • Use the API instance to initialize communication with the LMS
  • Use the API instance to terminate communication with the LMS

    Recommended SCO behaviors:
  • A SCO should be reusable in different learning contexts
  • A SCO should be independent of visual constraints, such as window size
  • A SCO should reliably transmit learner data so that it is not lost if closed unexpectedly
  • A SCO should communicate its completion status
  • A SCO should NOT launch new browser windows without closing them when done
  • A SCO should NOT link to other files in the content package not listed as resource files of the SCO in the manifest

    Restricted SCO behaviors:
  • A SCO may NOT interact with the run-time environment in any way other than the provided run-time API
  • A SCO may NOT attempt to change the size or appearance of the run-time environment it is launched in
  • A SCO may NOT close the top-level browser window it is launched in unless it is the only thing in the window

Typical SCO Lifecycle

  1. SCO is launched by a SCORM Run-Time Environment (RTE) (often an LMS)
  2. SCO finds RTE provided API
  3. SCO begins communication with the RTE API (via a call to Initialize())
  4. Learner begins interaction with the SCO
  5. SCO sends and retrieves data via the RTE API (via calls to Get/SetValue())
  6. Learner ends interaction with the SCO
  7. SCO ends communication with the RTE API (via a call to Terminate())


Next, learn more about SCORM Run-Time Environment.