SCORM Resources

In SCORM, a Content Object is a web-deliverable learning unit. At its most basic a content object is just an HTML page or document that can be viewed with a web-browser. A content object can use all same technologies a web-page can use (Flash, JavaScript, frames, images, etc). However, resources cannot be pages that require a server-side engine to process, such as ASP, PHP, or JSP pages.

Content objects are defined in a content package manifest file as a Resource, along with all the files it depends on. A Resource definition provides information about your learning object and how it may be used by a run-time environment.

Resources come in two flavors: Assets and Shareable Content Objects (SCOs).

An asset is a simple resource, such as a static HTML page or a PDF document, or collection of files, such as images and a style-sheet, which does not make use of the run-time API defined by SCORM. Therefore an asset does not communicate with the run-time environment delivering it.

A shareable content object (SCO) is a resource that communicates with the delivering run-time environment via the SCORM run-time API. SCOs and the Run-Time API are discussed in more detail later.

Resource Files and Dependencies

Each Resource will be registered along with the files it depends on in the manifest file. The listed files act as an inventory detailing the set of files, local to the content package, used to build the resource.

For instance, consider a learning object that is an HTML page that contains a Flash object and images. The learning object is registered as a resource. All the files of the learning object, including the HTML page, the Flash object, and its images, are the resource files.

A resource may also reference another resource as a dependency. For instance, one resource may reference another that defines a reusable collection of files, thus defining that the former resource uses the files of the latter.

Note that every learning object file in your content package listed as a resource or resource file. Additionally, every file listed in a resource element must be present in the content package. The .xsd and .dtd files used to validate the manifest and metadata files do not need to be listed as resources.

Trident allows you to drag-n-drop resources and automatically register them in the manifest. If the resource is an HTML file, as most are, Trident will even scan it to determine its dependency files and register those as well. All the XML is written for you. Trident will also validate your content package to ensure all registered resources are present in the package.

Launchable Resources and URLs

A resource may define a "launchable" content object or as a collection of files used by another resource.

A launchable resource must have an HREF specifying its launchable file, such as an HTML page. The HREF of a launchable resource is a URL, relative to the content package root directory, used to launch the content object. Resources of both SCORM-types, SCOs and Assets, may be launchable. Note that the first file listed for a launchable resource should be the file that is to be launched.

An example of a launchable resource is an HTML file meant to be displayed to a learner as a learning activity. The resource's files are all those the HTML file references, such as images, Flash files, etc.

A "non-launchable" resource acts as a container for a list of shared files used by other resources. These resources can be listed as dependencies of other resources. A non-launchable resource will always be of SCORM-type Asset.

An example of a non-launchable resource is a defined collection of files used by other resources. For instance, a style-sheet, script file, and image used in other launchable resources may be defined once and referenced by other resources. A non-launchable resource will likely be a dependency of one or more other resources.

Resource URLs are relative to the location of the manifest file (the root of the content package), so they may not begin with a "/". Resource URLs must use "/" as path separators to ensure they are web-browser and cross-platform valid.

Resource XML

The mandatory <resources> element in the manifest XML contains all of the resources.

    <resources> attributes:
  • xml:base - optional; relative path offset for the resources

    <resources> children:
  • <resource> - 1+ required; defines the content package's resources

A <resource> element defines a content object or collection of files.

    <resource> attributes:
  • identifier - required; an identifier unique within the manifest
  • type - required; the resource type, shall be set to "webcontent"
  • adlcp:scormType - required; the resource SCORM type, shall be set to "sco" or "asset"
  • href - optional; URL of the "launching point" of the resource
  • xml:base - optional; relative path offset for the files contained in the manifest/resource

    <resource> children:
  • <metadata> - 1 optional; resource metadata, described later
  • <file> - 1+ required; defines the resource's files
  • <dependency> - 1 optional; resource metadata, described later

Each <file> element defines a file used by the resource.

    <file> attributes:
  • href - the location of the file in the content package

Each <dependency> defines another resource used by this resource.

    <dependency> attributes:
  • identifierref - identifier of another resource within the same package

Note that all <file>s must be listed before all <dependency>s.

Code Example


Next, learn more about Organizations.