How will formatting issues,
such as layouts, fonts, color schemes, etc. be handled while allowing for interoperability
and sharability of learning products?
ADL has heard this referred to as the 'ransom note effect.' This is of course a
concern of and there are various efforts underway to look at how you can use the
idea of "skins", e.g. Windows Media Player skins, to work through that problem.
Also the World Wide Web Consortium (W3C) is doing work on standards to separate
content from navigation and design that
ADL hopes to be able to build on.
Back to Top
What hardware constraints,
such as minimum requirements for operating features, might come into play for SCORM
conformant learning products?
SCORM and ADL generally refer to 'Web-based' or 'browser-based' instruction. All
that is needed is a Web browser. An Internet connection is not always necessary.
ADL thinks that the vendors will really address this issue since the more widely
accessible their content and/or systems are, the more markets they will able to
access.
Back to Top
What topics does
SCORM address besides LMS/content exchange?
The launching of content and the exchange of data such as learner ID numbers and
test scores between
LMSs and content are among the most important topics addressed
by SCORM. These areas are addressed by the SCORM Run-Time Environment (RTE). SCORM also covers other critical
areas.
SCORM defines formats for "meta-data" or descriptions of course content that allow
reusability. Meta-data files contain information such as training objectives, prerequisites
and the sequence in which concepts should be presented. SCORM handles meta-data
through its Content Aggregation Model (CAM).
SCORM also addresses a standard way to structure and exchange learning content.
This occurs through the application of the IMS Content Packaging specifications.
SCORM also defines a method for representing the intended behavior of an authored
learning experience such that any
LMS will sequence discrete learning activities consistently.
This is accomplished through the application of the IMS Simple Sequencing Specifications.
Back to Top
Will SCORM conformant content
and SCORM conformant LMSs "plug-and play" with each other?
Probably. SCORM dictates how an LMS must make the
API available to the content, so content developers know exactly
how to write the ECMAScript code to locate and call the API. You might have problems
if the LMS and content support different versions of SCORM, which is rapidly evolving.
The current version is SCORM Version 1.2, with SCORM Version 2004 slated for release
early in the first quarter of 2004. Many products adhere to the previous version,
SCORM Version 1.1. Fortunately, from the perspective of LMS/content data exchange,
the differences between SCORM Version 1.1 and 1.2 are minor. (For more information
on the differences refer to SCORM Version 1.2: The SCORM Run-Time Environment, Appendix
C: "Revision History.") If there are version-related compatibility problems, the
content vendor may be able to make simple changes to address them. Any changes between
SCORM Version 1.2 and Version 2004 will be addressed as they arise.
Back to Top
Does SCORM allow multiple
ways for LMSs and courseware to exchange data?
No. SCORM requires use of the ECMAScript API defined in the SCORM RTE book.
Back to Top
Are there LMS specification
standards?
SCORM does not try to standardize the implementation of LMSs. Although there are
some "behavioral" requirements imposed upon the LMS by the standardized communication
mechanism. SCORM wants, primarily, to ensure that courses run and behave the same
on different LMSs. There are no requirements for how the LMSs are designed and implemented.
This is left to the LMS vendor to address, and each does so differently targeting
different market areas and consumer needs. The goal of ADL is, in part, to provide
standards that allow content to be interoperable and sharable. We believe standardizing
the communication mechanism takes us most of the way toward that goal.
Back to Top
What size must the learning
resource (Sharable Content Object or Assest) be to conform to SCORM?
There are no SCORM-imposed requirements on size of learning resources. The size
of learning resources must be thought of early on in the development cycle. Size
should be based on several aspects:
- Reuse
- Objectives of the learning resource
- Pedogogical Model being used.
Back to Top
Why must I copy
XML Schemas to the Windows Desktop when I run the SCORM Conformance Test Suite?
Due to implementations used with the Xerces
XML parser, it is necessary to copy any needed XML Schemas (.xsd
files) to the Windows Desktop for both Meta-Data and Content Package testing. This
constraint is being investigated and will be addressed in an upcoming release of
the SCORM Conformance Test Suite.
Back to Top
What is a Packaging Interchange
File (PIF)?
A Package Interchange File (PIF) is a single file ( such as a .zip file) that includes
a top-level Manifest file named "imsmanifest.xml" and all other physical files as
identified by the Manifest. A PIF is a concise Web delivery format and a means of
transporting related, structured information.
Back to Top
What is a Package?
A Package is a logical directory, which includes a specially named XML file, any
XML control documents it references (such as XSDs), and sub-directories containing
the actual physical resources.
A package represents a unit of usable (and resusable) content. This may be part
of a course that has instructional relevance outside of a course organization and
can be delivered independently, as an entire course or as a collection of courses.
Packages are not required to be incorporated into a Package Interchange File (PIF).
A package may also be distributed on a CD-ROM or other removable media without being
compressed into a single file. An IMS Manifest file and any other supporting XML
files required (e.g. XSD) must be at the root of the distribution media.
Back to Top
Does learning
content need to use the SCORM Application Programming Interface (API) to be SCORM
conformant?
Sharable Content Objects (SCO) are required to only perform the following:
- Find the LMS provided API Instance.
- Invoke the Initialize("") API function when ready to begin communication with the
LMS provided API instance.
- Invoke the Terminate("") API function when ready to end communication with the LMS
provided API Instance.
Asset is not required to communicate with the LMS provided API Instance.
Back to Top
Use of XML Base
XML Base is a construct used to explicitly specify the base URI of a document in
resolving relative URIs in links to external files. In the imsmanifest.xml file,
internal and external references may be absolute or relative. Relative addresses
can be prefixed by an xml:base attribute. The xml:base attribute allows both external
and local base addresses to be specified. Relative URLs, in the absence of xml:base,
are relative to the Package root (location of the imsmanifest.xml). In the presence
of an xml:base path, relative URLs are relative to the path specified in xml:base.
When an xml:base path is relative itself, the absolute path is then resolved to
the location of the containing document. That is, the location of the imsmanifest.xml
file in an importing system, when it is read, supplies the missing absolute segment,
per rules expressed in RFC 2396. In the presence of an xml:base path, which references
an external location, the relative URLs are relative to that location. Absolute
(external) URLs are considered to be fully-specified without the provision of additional
pathing.
When using xml:base in packaging, the xml:base path should not begin with a leading
forward slash. As defined in RFC 2396, a path with a leading forward slash indicates
the absolute path of that resource. Using a leading forward slash can easily be
misinterpreted as declaring the document as the local host. With this in mind, the
x:base attribute is most useful for specifying relative paths to sub-directories
containing content Package resources.
For more information on XML Base visit the W3C Web site (http://www.w3c.org/).
Back to Top
Use of metadata vs. use
of the HTML "meta" tag
When talking about metadata within SCORM, we are referring to meta-data as a stand-alone
entity. This is not to be confused with the use of the
tag that exists within the WC3 HTML specification. We are not saying that you cannot
use this
tag, only that we are not referring its specific use in the SCORM specification.
When developing SCORM conformant content, the metadata for this content exists as
a stand-alone entity. Once this stand-alone entity is created, it can be associated
to the learning resource via the manifest (imsmanifest.xml) file. The manifest file
can contain in-line metadata meaning the actual metadata elements are included within
the other XML forming the manifest file, or the
element can be used to reference the location of a metadata instance found outside
of the manifest.
Back to Top
Use of (sub)Manifests
When to use (sub)Manifests?
The implementation is entirely up to the content developer as long as the content
developer follows the requirements outlined in SCORM.
The scope of a manifest is elastic. The manifest can describe part of a course that
can stand by itself outside of the context of a course (an instructional object),
an entire course, or a collection of courses. The decision is given to the content
developers to describe their content in the way they want it to be considered for
aggregation and dissaggregation. For example, if all content comprising a course
is so tightly coupled that no part of it may be presented out of the course context,
a content developer would want a single manifest to describe that course's resources
and organization. However, content developers who create 'instructional objects'
that could be recombined with other 'instructional objects' to create different
course presentations would want to describe each 'instructional object' in its own
manifest, then aggregate those manifests into higher-level manifests containing
a course organization. Also, a content developer who wants to move multiple courses
in a single package (a curriculum), would use a top-level manifest to contain each
course-level manifest and any instructional object manifests that each course might
contain.
An 'instructional objects' could be any form of a content aggregation (e.g., modules,
lessons, chapters, etc...).
There is still some unanswered questions in the IMS Content Packaging Working Group
dealing with the use of (sub)Manifests. This is work that should be addressed in
the next release of their specification. For more information and guidance please
see the IMS Content Packaging Specification (http://www.imsglobal.org/).
There are three documents that you may be interested in reading:
- The IMS Content Packaging Information Model
- The IMS Content Packaging XML Binding
- The IMS Content Packaging Best Practice Guide.
These documents form the basis of SCORM 2004 (Version 1.3) work dealing with Content
Packages.
Back to Top
Overview of ADL Metadata
Specifications
The work of the ADL Initiative to develop SCORM is also a process to knit together
disparate groups and interests. This reference model aims to coordinate emerging
technologies with commercial and/or public implementations. SCORM defines the application
requirements and guidance in the use of the
IEEE 1484.12.1-2002 (more commonly referred to as Learning Object
Metadata, or
LOM).
Back to Top
Representing query strings
or launch parameters in a Manifest
Listed below are two mechanisms for representing launch parameters or query strings
in a Manifest. Other representations may exist to allow the content developer to
provide this information.
- As part of the <resource> or <file> href. The content developer can
place the query string or launch parameters as part of the href. An example of this
is:<resourcehref="foo.html?Topic=1">
- Using the parameters attribute of the <item>. The content developer also has
the option of placing the query string or launch parameters in the parameters attribute
of the
- referencing the . The parameters
attribute is defined as the static parameters to
be passed to the resource at launch time. This
allows for the ability to reference the same
from different items for different purposes. In option 1, each Resource must be
repeated in the Manifest.
An example of this is: <item identifier="I01" identifierref="R_I01" parameters="Topic=1">
<item identifier="I02" identifierref="R_I01" parameters="Topic=2"> <resource
identifier="R_I01" href="foo1.htm">
IMS Content Packaging Version 1.1.3, released June 12, 2003, has made some additions
to clarify parameter processing requirements. These additions do not directly affect
what is discussed in this article.
Back to Top
Handling of
bookmarks in the CMI Data Model
Keeping track of the location inside of a SCO for a student can be accomplished
using the cmi.core.lesson_location data model element. This element can be set from
with the SCO and retrieved upon launch of the SCO. The cmi.core.lesson_location
corresponds to the SCO's exit point passed to the LMS system the last time the student
experienced the SCO. This provides a mechanism to let the students return to the
SCO at the same place they left it in another session. In other words, this element
can identify the student's exit point and that exit point can be used by the SCO
as an entry point the next time the student wants to take the SCO. In the future,
a new data model may be introduced for bookmarking capabilities.
Back to Top
|