Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.

IMS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on IMS's procedures with respect to rights in IMS specifications can be found at the IMS Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.

Copyright ) 2008 IMS Global Learning Consortium. All Rights Reserved.

Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals.

The limited permissions granted above are perpetual and will not be revoked by IMS or its successors or assigns.

THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.

Executive Summary

The Common
Cartridge defines an open format for the distribution of rich,
web-based content. It is designed to ensure the correct
installation and operation of content across any Common Cartridge
conformant platforms and tools. The specification defines a
profile for the use of the following specifications which are (in
the versions adopted here), already widely implemented and in use
across the community:

The LOM, Content Packaging and Question
& Test Interoperability specifications have each been
profiled to simplify their use. Thus their scope has been
constrained to those features commonly implemented and in use by
the community. Experience suggests that interoperability problems
that have arisen with implementations of these specifications are
frequently the result of differing interpretations of the specs
and options being taken that lead to divergence in behavior. A
key goal of the Common Cartridge specification therefore has been
to provide a tighter definition of their use thus eliminating
this divergence. The resulting profile also lends itself to more
effective conformance testing of implementations.

Additional features offered by the Common
Cartridge include:

A new resource type for initiating
discussion forum interactions.

Inclusion of a question bank (i.e., a QTI
objectbank), offering tutors additional questions to those
contained within the pre-configured assessments, which they can
configure around the core material.

The present versions of the specifications
supported under Common Cartridge have been selected to offer
existing implementations a low barrier to adoption of the Common
Cartridge. It is to be anticipated that as new versions of these
specifications achieve widespread adoption, they in turn will be
adopted thus further enhancing the features supported in future
versions of the Common Cartridge.

The profile has been developed in
accordance with the IMS Application Profile Guidelines v1.0,
using the IMS SchemaProf tool v1.0.

The driving motivation behind this work has
been to communicate clearly and unambiguously how the above
collection of specifications can be harnessed to distribute rich
web content in a format offering a high degree interoperability
across platforms. The approach followed has centered on;

The resulting Common Cartridge profile
should be easier for developers to implement and lends itself to
more routine conformance testing of these implementations.

1.1.2 Technology

Simplifications applied to the Common
Cartridge format include:

Meta-data is only mandated at the cartridge
level by the CC profile (located in the root folder). Optionally,
roles meta-data can be applied within the manifest to define
which categories of users have access to particular
resources.

Inter-package links are not supported

Common Cartridge meta-data only uses the 15
elements from DCMI v1.1 (Simple DC)

Assessments have been simplified to just
the six (6) most commonly used QTI question types:

Multiple choice (single response)

Multiple choice (multiple response)

True/false

Essay

Simple fill in the blank

Pattern match

However, the format has also been enriched
with the addition of:

Cartridge support for authorization data
(also see the Authorization Web Service specification [CC,
08b])

Addition of discussion forum
initialization

1.1.3 Deployment

Figure 1.1 Common Cartridge Focus.

The primary focus of the Common Cartridge
specification is achieving error-free import of content into any
conforming LMS platform (see Figure 1.1). No runtime model is
expressed, but any conforming LMS must support (either directly,
or via a call-out to a suitable external service) all of the
functionality implied by the Common Cartridge schema set. In
particular, a conforming LMS must fully implement the
Authorization web service. The cartridge can optionally require
the following forms of authorization:

Authorization on import - licensed
site

Authorization of learner runtime access -
applied to package or item.

1.2 Structure of this document

The structure of this document is as
follows:

2. Use Cases

Describes the following use cases which
have driven the development:

CC package import

Authorization

Execution of static content

Execution of dynamic content -
client-side

Execution of dynamic content -
server-side

3. Architecture & Approach

Provides coverage of the cartridge
structure and supported resource types.

4. Common Cartridge Information Model
Profiles

Documents the UML corresponding to the
Common Cartridge profile schema set, along with xml extracts to
demonstrate how features are to be implemented...

5. Implementation Guidelines & Best
Practice

Offers further advice on implementation
issues, in particular addressing examples of valid Common
Cartridge file structures.

6. Conformance

Summarizes how conformance of
implementations against the specification will be evaluated.

Appendix A - Profile XSDs

The URL for downloading the CC WSDL/XSD
files

Appendix B - Profile Schema Package

The full set of files that define the
Common Cartridge Application Profile.

1.4 Definitions

Term

Definition

Access Code

A code used to authorize user access to a
protected resource, in this case a Common Cartridge or a discrete
component thereof.

Associated Content

A resource type that includes a collection
of files used by a specific Learning Application Object. Each
file referenced must exist in the directory containing the
descriptor file of the Learning Application Object with which it
is associated or any subdirectory thereof.

A resource of the type "associatedcontent"
must comply with the following restrictions:

1. It must contain a file element for each
file that exists in the directory that contains the associated
Learning Application Object's descriptor file or any of its
subdirectories.

2. It must not contain any references to
files above the directory containing the associated Learning
Application Object's descriptor file.

3. It must not contain any dependency
elements.

Common Cartridge

A content packaging profile agreed between
content providers and LMS providers, offering a common format for
the distribution of both open and access protected content. The
profile harnesses Content Packaging, LOM Metadata, and QTI,
augmented with a specification for simple access control.

Content Elements

Discrete content elements within a Learning
Activity aggregate as part of a Learning Application Object or
module (lesson).

Course Content Package

A term for any current proprietary LMS
specific, publisher developed and sourced, content package that
is made commercially available via the publisher or LMS vendor to
its customer base. Examples of such cartridges are the WebCT
ePack, Blackboard Course Cartridge etc.

Deployment Context

Any one of the LMS deployment and learning
contexts made available for online access to learning activity
via learning modules, Learning Application Objects and content
element interaction.

Descriptor File

The file that serves as the entry point for
accessing the information about a Learning Application Object
required to import the Learning Application Object into the
target system. Generally an XML file meeting an appropriate file
specification based on the type of Learning Application Object.
However, in some cases, the file may be a zip archive or some
other structured file format. The descriptor file is not intended
to be displayed within the target system. Rather, it is intended
to be processed by the target system upon import of the
cartridge. The descriptor file is associated with a Learning
Application Object by means of a "file" element.

Directory

A physical folder in a content package
archive.

Learning Activity

A general term for describing an online
learning experience and interaction with learning modules,
Learning Application Objects and content elements typically
composed to deliver a particular outcome or experience for the
Student.

Learning Application Object

Any one of a number of resource types that
require additional processing and interpretation before they can
be imported and subsequently represented within the target
system. Physically, a Learning Application Object consists of a
directory in the content package containing a descriptor file and
optionally additional files and subdirectories used exclusively
by that Learning Application Object.

Each Learning Application Object must have
a corresponding resource element in the manifest. Examples of
Learning Application Objects include QTI assessments, Discussion
Forums, etc. The type attribute of the resource element is
prescribed by the type of Learning Application Object being
represented. If additional files beyond the Learning Application
Object's descriptor file exist in the Learning Application
Object's directory or any of its subdirectories, these files must
be represented in a resource element of type "associatedcontent"
which is list as a dependency within the Learning Application
Object's resource element.

A resource that represents a Learning
Application Object has the following general restrictions:

1. It must contain a file element that
points to the Learning Application Object's descriptor file.

2. It must not contain any other file
elements.

3. If additional files exist in the
directory containing the Learning Application Object's descriptor
file, or any of its subdirectories, the resource must contain a
dependency element that references the resource of type
"associatedcontent" which contains the references to these
files.

4. It must not contain any other dependency
elements of type "associatedcontent".

5. It may contain any number of dependency
elements that reference resources of type "webcontent".

Learning Management System

A Learning Management System (LMS) is a
computer application that enables the assignment of content to
learners, learning, and the reporting of learning outcomes. This
is used interchangeably with Course Management System, Managed
Learning Environment and a host of other terms.

Learning Module

An aggregate of content and/or application
functionality that represents or is part of a learning
activity.

Target System

A Learning Management System (LMS) or
similar system into which a package is to be imported.

webcontent

The standard resource type for content
packages. Static web resource that is generally supported on the
web such as HTML files, GIF images, JPEG images, PDF documents,
etc. Resources of the type "webcontent" may reference any number
of files. Additionally, "webcontent" resources may include
dependencies on other "webcontent" resources.

A resource of the type "webcontent" must
comply with the following restrictions:

1. It may contain a file element for any
file that exists in the package so long as the file is not in a
Learning Application Object directory or a subdirectory of any
Learning Application Object directory.

2. It may contain dependency elements that
reference any other resources of type "webcontent".

It must not contain any dependency elements
to resources whose type is not "webcontent".

2. Use Cases

2.1 Use Case Scope

2.1.1 Affected Roles and Definitions

Table 2.1 Common Cartridge User Roles.

Role

Definition

Student

LMS Learner

Instructor

LMS Faculty member leading the
course/learning activity. Includes Teaching Assistants or
equivalent where applicable.

4. Cartridge data is integrated into a
deployment context within the LMS.

Variations

2.1 LMS provides an "import gate" requiring
PIN authentication for the cartridge to import. This is
independent of the 2.3 Authorization use case, which implies "on
learner/item use" authorization. This implies that authorization
meta-data in the package has a discriminator for the type and
granularity of authorization, e.g., "on import", "on package
use", or "on item use".

3.1 LMS provides a list of material in the
cartridge for selective import. The LMS may or may not provide
preview capabilities. Because cartridges and contained resources
may contain arbitrarily complex data and dependencies, such
preview will be very limited.

3.2 Instructor selects items for
import.

3.3 LMS imports selected items, ensuring
that any required dependencies are met. E.g., an assessment that
retrieves questions from an question bank must ensure that the
question bank is imported, even if the Instructor did not
specifically select the question bank.

4.1 Import may require an expensive,
non-interactive process, so errors that affect the integrity of
the cartridge will be logged for review. The format and available
end user actions are LMS dependent.

Exception Conditions

Data format errors (e.g., the cartridge is
not a .zip file, the manifest is missing or incorrectly named) of
the cartridge prevents LMS from reading the package.

3. If no record exists, LMS provides a
prompt for entry of a simple access control token. The
distribution of the tokens is out of scope for this
specification.

4. LMS processes token, asserting the
validity against an authorizing authority. The authorization
algorithm is authorization server dependent and out of scope for
this specification. The specification only defines "when"
authorization is to occur, and at what level (package or for each
"protected" item). A valid cartridge must use CC authorization
were authorization is stipulated in a cartridge.

Variations

1.1 Learner navigates to a specific item
that requires authorization, and is keyed to trigger "per item"
authorization.

2.1 LMS evaluates any expiration rules for
authorization that might be defined in the cartridge or stored
with the authorization record.

Exception Conditions

Learner-provided token is invalid.

Authorization cannot occur due to system
errors (network communication to authorizing authority,
etc.).

4. LMS creates a suitable display element
(e.g., new window, frameset) that includes a client-accessible
moniker for the resource (e.g., a URL to load the resource.

Variations

4.1 Resource (resource element and
associated files) contains links to other components within the
same resource. The LMS is responsible for maintaining the file
system of the resource so that relative URIs are automatically
de-referenced. If the LMS translates the file system, either at
cartridge deployment time or content delivery time, it must do so
in a way that is transparent to content authors. For this reason,
inter-content linking between arbitrary content types is out of
scope, because many kinds of resources will require LMS-dependent
URI generation. E.g., a QTI XML file will most likely require a
LMS-generated URI for launch. For the LMS to parse and replace
content references is likely to be extremely fragile, even for
common "web" data types, such as PDF or Shockwave data.

Exception Conditions

Static content cannot be read by the client
(e.g., no Flash player installed).

Network or protocol errors between the
client and the server.

2.5 Execution of Dynamic Content -
Client-side

Use Case 4(a)

Execution of Dynamic Content -
Client-side

Level

Summary

Primary Actor(s)

Student (LMS Learner)

Secondary Actor(s)

Instructor, Instructional Designer, LMS

Trigger

Student needs to access and complete a
Learning Activity that is:

comprised in whole or part by learning
modules, Learning Application Objects and content elements.

sourced as a learning module or from a
discrete collection of Learning Application Objects and content
elements, imported into the LMS, and made available via the
Instructor/Instructional Designer-developed content and/or
imported content cartridge elements.

LMS pre-existing/accessible learning
modules, Learning Application Objects, and content elements can
be leveraged in combination with any Common Cartridge elements to
construct the Learning Activity context.

Preconditions

Content cartridge learning modules,
Learning Application Objects, and content elements are imported
into a specific LMS deployment context that is, in turn,
accessible to the Instructor/Instructional Designer and, of
course, to the Student.

LMS enables import and use/reuse of Content
cartridge elements within one or more of its deployment
contexts.

Success Post-conditions

Learner activity launched and user/Learner
is directed to interact with the learning module and its
component Learning Application Object and content elements.

2. Student initiates a navigation event
triggering start of (i.e. sequence beginning) or entry into a
specific learning module (e.g., clicks on the learning
activity/module table of contents (TOC) element or directly on an
embedded link to an element rendered by the LMS).

4. LMS learning activity run-time invokes
the appropriate client-side viewer/player component and passes to
it the context and/or content stream or reference of the learning
module to be presented the user/Learner via the client-side
viewer/player.

5. LMS learning activity run-time passes
control with established context to the client-side viewer-player
to then control the presentation of and interaction with the
learning module to Student.

6. LMS authenticates/authorizes any
implicit or explicit security assertions required to access or
interact with the learning module and any of its contained
elements as part of the interaction.

7. Student initiates and interacts with
learning module and performs the required Learning Application
Object interaction and content review so a to complete the
activity and derive any outcome expected from the
interaction.

8. Student completes the interaction with
the learning module representing all or part of the original
Learning Activity.

9. Upon completion of the interaction, any
residual outcome is captured by the viewer-player and marshaled
back to the LMS learning activity run-time.

11. The Student/user is returned to the
originating context in a state to proceed with the next Learning
Activity interaction based on selective choice by Student and/or
automated target based on some predefined sequence or prior
outcome affected specific target.

comprised in whole or part by learning
modules, Learning Application Objects, and content elements.

sourced as a learning module or from a
discrete collection of Learning Application Objects and content
elements, imported into the LMS, and made available via the
Instructor/Instructional Designer-developed content and/or
imported content cartridge elements.

Preconditions

Content cartridge learning modules,
Learning Application Objects, and content elements are imported
into a specific LMS deployment context that is, in turn,
accessible to the Instructor/Instructional Designer and, of
course, to the Student.

LMS enables import and use/reuse of Content
cartridge elements within one or more of its deployment
contexts.

LMS pre-existing/accessible learning
modules, Learning Application Objects, and content elements can
be leveraged in combination with any Common Cartridge elements,
to construct the Learning Activity context.

Success Post-conditions

Learner activity launched and user/Learner
is directed to interact with the learning module and its
component Learning Application Object and content elements.

2. Student initiates a navigation event
triggering start of (i.e., sequence-beginning) or entry into a
specific learning module (e.g., clicks on the learning
activity/module table of contents (TOC) element or directly on an
embedded link to an element rendered by the LMS).

4. LMS authenticates/authorizes any
implicit or explicit security assertions required to access or
interact with the learning module and any of its contained
elements as part of the interaction.

5. LMS learning activity run-time
establishes the presentation and interaction context for the
requested learning module so as to manage and control the
end-user Student interaction.

6. Student initiates and interacts with
learning module and performs the required Learning Application
Object interaction and content review so as to complete the
activity and derive any outcome expected from the
interaction.

7. Student completes the interaction with
the learning module representing all or part of the original
Learning Activity.

8. Upon completion of the interaction, any
residual outcome is captured by the LMS learning activity
run-time.

10. The Student/user is returned to the
originating context in a state to proceed with the next Learning
Activity interaction based on selective choice by Student and/or
automated target based on some predefined sequence or prior
outcome affected specific target.

3. Architecture and Approach

3.1 IMS Common Cartridge Run-Time
Functional Model

Figure 3.1 Common Cartridge Run-time
Model.

3.2 Content Types

Figure 3.2 Common Cartridge Content
Types.

The following describes the content types
supported by the Common Cartridge specification v1.0.

Table 3.1 Common Cartridge Content
Types.

Entity

Description

Item - Folder

A folder represents a unit of organization.
A folder is simple collection of items and subfolders that are
placed in a specific order (1st, 2nd, 3rd, etc.). Folders can
contain other Folders (n-level nesting). A folder represents a
content presentation paradigm and can be used to define how the
content should be organized and presented to the learner.

Resource - Web Content

Web Content files include any files that
are widely supported for delivery over the web. These could
include HTML files, images, audio, video, MS Office, PDF, Flash
etc.

HTML files may include references to other
web content files that are contained within the cartridge or that
are external to the cartridge.

Resource - Web Link

A Web Link is a Learning Application Object
representation of a standard HTTP link. It extends a standard
HTTP link by giving the link a title (which is independent of its
usage in any particular folder location). It also includes
attributes that describe which window the resource should be
opened in and other window open features, such as the dimensions
of the window.

Resource - Discussion Topic

A Discussion topic is a Learning
Application Object that is used to initiate Discussion activity.
This represents a placeholder for a discussion topic and does not
represent a link to an existing discussion topic in an external
system. The importing LMS is expected to generate a new
discussion topic using only its internal tools. It contains the
following attributes: title, description, file attachments.

Resource - Assessment

An assessment represents an instance of a
QTI assessment. It can embed any of the question types supported
by the CC v1.0 profile of QTI.

An assessment can contain a number of
attributes including number of attempts, time limit and whether
late submission is allowed.

Resource - Associated Content

A collection of files used exclusively by
an individual Learning Application Object

Intra-Package Reference

Intra-Package References allow Learning
Application Objects or files in the package to reference other
files within the package.

IMS CC Package Meta-data

This is IMS CC Package level specific
meta-data that may include different elements covering licensing,
accessibility, description, etc.

Question Bank

A question bank represents an instance of a
QTI objectbank. Only one question bank can optionally be included
in a cartridge. It can embed any of the question types supported
by the CC v1.0 profile of QTI. Questions within a question bank
cannot be referenced by any assessments contained in the
cartridge.

Common Cartridge v1.0 supports profiled
instances of the following question types:

3.3 Common Cartridge Package Interchange
File Structure

The diagram in Figure 3.3 shows the overall
layout of the cartridge package interchange file.

Figure 3.3 Common Cartridge package
interchange file.

3.3.1 Categories of Resource in a Common
Cartridge

In addition to the imsmanifest.xml file,
there are a further three basic categories of resource file in a
Common Cartridge.

Table 3.2 Common Cartridge Resource
Categories.

Resource Category

Description

imsmanifest.xml

This is the standard IMS manifest file

Web Content Resources

These include the following resource types: web content, web link or intra-package reference (see table 3.1).

Web Content Resources must reside within the web content folder at the root of the cartridge. The Web Content Resources can here be organized into directories and subdirectories within the web content folder.

Web Content Resources within the web content folder can be referenced by other resources outside of the web content folder directory system.

Web Content Resources within the web content folder can be referenced by other resources also within the web content folder directory system.

The directory structure within the web content folder will be included in the importing LMS to ensure relative links between and to web content continue to work.

Generally, Web Content Resources do not require additional processing on import into the LMS, although how these are stored and rendered is LMS dependent.

Learning Application Object Resources

A Learning Application Object is a directory structure used to group together all the files (or file references) that are used to deliver a single instance of one of the following resource types: web content, web link, discussion topic, assessment or intra-package reference (see table 3.1).

The files held within a Learning Application Object directory structure are described as Associated Content Resources.

The directory structure within the Learning Application Object folder will be included in the importing LMS to ensure relative links between and to web content continue to work.

These will generally be parsed on input and transformed into internal data structures in the LMS.

Using Directories in Package Interchange
File

File system directories can be used to
organize content within the package interchange file. It is
required that the resources specific to a given Learning
Application Object are packaged in a distinct directory in the
package interchange file.

Associated Content resources include a
collection of files used by a specific Learning Application
Object. Each file referenced must exist in the directory
containing the descriptor file of the Learning Application Object
with which it is associated or any subdirectory thereof.
Furthermore, each Associated Content resource must be associated
with one and only one Learning Application Object. This
association is indicated by use of a dependency reference on the
Learning Application Object's resource element.

A resource of the type "associatedcontent"
must comply with the following restrictions:

It must contain a file element for each
file that exists in the directory that contains the associated
learning application object's descriptor file or any of its
subdirectories.

It must not contain any references to files
above the directory containing the associated learning
application object's descriptor file.

It must not contain any dependency
elements.

Web Content resources include any number of
references to static web resources that are generally supported
on the web such as HTML files, GIF images, JPEG images, PDF
documents, etc. Resources of the type "webcontent" may reference
any number of files. Additionally, "webcontent" resources may
include dependencies on other "webcontent" resources. However,
"webcontent" resources may never contain dependencies on any
other resource types including Associated Content resources and
Learning Application Object resources.

A resource of the type "webcontent" must
comply with the following restrictions:

It may contain a file element for any file
that exists in the package so long as the file is not in a
learning application object directory or a subdirectory of any
learning application object directory.

It may contain dependency elements that
reference any other resources of type "webcontent".

It must not contain any dependency elements
to resources whose type is not "webcontent".

3.3.3 Learning Application Object
Directories

These directories organize all the files
that logically contribute to the delivery of a single instance of
one of the content types supported by Common Cartridge.

The root of the directory should contain
the descriptor file for the Learning Application Object such as
the QTI file for an assessment Learning Application Object. This
directory may also contain additional files and subdirectories
that are used exclusively by the Learning Application Object
(i.e., associated content).

The name of this directory is not defined
by the specification. Care must be taken to ensure that
collisions do not occur between this directory name and the names
of directories used for other Learning Application Objects and
those used for web content.

A cartridge that does not contain any
additional Learning Application Objects (e.g., only cartridge
level web content) may exclude these directories.

3.3.3.1 Associated Content

Any web content which is logically tied to
this Learning Application Object should be contained in the
Learning Application Object resource directory.

All references to this content from
Learning Application Object resource files e.g. QTI files should
use a relative path.

It is the responsibility of the cartridge
producer to ensure name collisions do not occur between end user
created file/folder names (for web content) and system generated
file/directory names (for resource descriptors).

3.3.4 Example Layout

An example of the layout described above
could be:

imsmanifest.xml

course-logo.gif

course-overview.html

content1/preTestQti.xml

content1/images/map.gif

content1//movie.swf

content1/background.html

content2/discussionTopic1.xml

content2/overview.html

content2/images/image.gif

content3/webLink1.xml

3.4 Pathnames for Web Content
Resources

To facilitate management of web content
resources, in particular utilizing standard html relative path
referencing between resources when content is imported into the
LMS, web content resources are defined to live in two file
systems - a folder for web content used by several resources and
a folder for each Learning Application Object's related
content.

The diagram in Figure 3.4 shows how web
content may be referenced across these different file systems
using relative path semantics.

Figure 3.4 Content referencing using
relative file paths.

3.4.1 Cartridge Web Content

A Cartridge Web Content folder may be
included in a Common Cartridge. If present, the Cartridge Web
Content folder must appear in the root folder of the cartridge.
The name of this folder is not defined by the specification.

Web content included in the Cartridge Web
Content folder can be referenced by any of the Learning
Application Objects in the cartridge. Relative path referencing
is permitted between files in this folder and its subfolders, but
files in this folder are not permitted to reference files in a
Learning Application Object folder or its associated content
folders.

On import, an LMS will usually import this
content into a course level file system.

3.4.2 Learning Application Object Web
Content

There can be 1 to n Learning Application
Object web content folders in a Common Cartridge.

Each Learning Application Object in the
cartridge has its own associated content file system folder.
Files in this folder and its subfolders may reference other files
in this associated content file system folder and files in the
Cartridge Web Content folder using relative path semantics.
However, they must not reference files in other Learning
Application Object web content folders or their sub-folders. In
addition, Learning Application Object resources (e.g., a QTI xml
file) can contain references to files in the Learning Application
Object's associated content folder and its subfolders and the
cartridge web content folder and its subfolders, but must not
contain references to web content in the folders of other
Learning Application Objects.

On import, an LMS that only supports a
single course level file system may import this web content into
the course level file system. In this scenario, the web content
in the cartridge represents one big file system scope.

An LMS that supports both course level and
Learning Application Object level file systems will import this
content into a local file system space that can only be utilized
by the associated Learning Application Object.

3.4.3 Format of Relative Path References
within a web content file system

All html path linking (e.g. <img
src="">, <a href="">) between content contained in a
given file system (cartridge or Learning Application Object)
should utilize relative path semantics restricted by the rules
defined above. Here relative path is defined as relative to the
file containing the reference regardless of whether that file is
itself web content or some other resource e.g. a QTI file.

3.4.3.1 Referencing Web Content from other
Web Content

Within a given file system, paths are
relative to the location of the file, e.g., for the files:

content1/material/lesson.html

content1/images/icon.gif

An image reference to icon.gif from
lesson.html would take the form:

<img src="../images/icon.gif"/>

3.4.3.2 Referencing Web Content Directly
from other Resources Using a Defined Linking Syntax

Where the linking syntax of a learning application object uses a URI, paths should be relative to the file containing the reference, e.g., for the files:

content1/question1Qti.xml

content1/images/icon.gif

A QTI matimage element would take the
form:

<matimage uri="images/icon.gif">icon.gif</matimage>

3.4.3.3 Referencing Web Content from
Embedded Text in Another Resource

Where a Learning Application Object
resource supports free-form text which may contain embedded HTML
markup, paths should be relative to the file containing the
reference and should in addition contain a special token to make
finding and parsing these paths simpler for the importing system,
e.g., for the files:

content1/question1Qti.xml

content1/images/icon.gif

A reference to the image icon embedded in
the free format question text should take the form:

<img src="$IMS-CC-FILEBASE$images/icon.gif"/>

Note: the token $IMS-CC-FILEBASE$ is just a
flag to facilitate finding the paths. It does not represent a
replacement token within the context of the cartridge. However,
an importing LMS may choose to store the referenced files in a
different location and so is free to insert any path elements
needed to make the path work in the LMS.

All html path linking (e.g. <img
src="">, <a href="">) by content contained in a Learning
Application Object file system to content in the cartridge web
content file system should use relative paths adhering to similar
rules as those defined for references within a file system. Here
relative path is defined as relative to the file containing the
reference regardless of whether that file is itself web content
or some other resource, e.g., a QTI file.

The key rule is that where a relative path
within the Learning Application Object file system is directed
above that file system root, this is assumed to be a reference
into the cartridge web content file system, e.g., for the
files:

images/icon.gif

content1/material/lesson.html

An image reference to icon.gif in the
cartridge file system from lesson.html in a Learning Application
Object file system would take the form:

Where a Learning Application Object
resource supports free-form text which may contain embedded HTML
markup, paths should be relative to the file containing the
reference and should in addition contain a special token to make
finding and parsing these paths simpler for the importing system,
e.g., for the files:

images/icon.gif

content1/question1Qti.xml

A reference to the cartridge image icon
embedded in the free format question text should take the
form:

<img src="$IMS-CC-FILEBASE$../images/icon.gif"/>

4. Common Cartridge Information Model
Profiles

4.1 The Conceptual Model

The intent of this section is to provide a
high-level description of a Common Cartridge. While conceptually
similar to "cartridge-like" features found in existing commercial
vendor solutions, several of the features of the Common Cartridge
are included.

Conceptually, a Common Cartridge is a
package of content and meta-data that is integrated into an LMS
learning context. At a high level, this may directly correspond
to the notion of "course" in the target LMS. There is no
guarantee of the cardinality of the relationship from "learning
context" to "Common Cartridge", i.e., the LMS may enforce an
arbitrary 1-1 relationship. The data contained in the package
breaks down into the following categories:

"Learner Experience" Data. These are the
resources presented directly to the learner, i.e., content
resources.

Supplemental Resources. These are resources
that may be optionally integrated into the learning context by an
instructor or other facilitator. E.g. question bank.

Operational Data. Data used to control
behavioral aspects of the LMS display/interaction with the
cartridge. E.g. authorization.

Descriptive Meta-data. This is the defined
IEEE LOM data, and is represented via existing bindings.

A Common Cartridge is an IMS Content
Package conforming to the following basic structure.

A Common Cartridge may define a single
organization, or include no organization. Multiple organizations
are not permitted and the default attribute for organizations is
not therefore supported. The single organization is used on
import to integrate with the learning context, and defines the
basic navigation structure for the package. The organization
assumes the predefined "hierarchical" structure.

Only "Learner Experience" resources may be
included in the <organization> hierarchy.

Supplemental resources must not appear in
the organization. The LMS provides a way for the
instructor/facilitator to inspect/deploy/utilize these resources
as they see fit.

Common Cartridge resources must be
identified with GUIDs, in order to facilitate proper integration
in systems that execute "by reference" content usage.

4.2 Supported Resource Types

Table 4.1 Common Cartridge Supported
Resource Types.

Resource Type

Constraints

Web Content

0 or more

Associated Content

0 or more

QTI Assessment (CC Profiles)

0 or more

QTI Question Bank (CC Profiles)

0 or 1

Authorizations Data

0 or 1

Discussion Topic

0 or more.

Web Links

0 or more

4.3 Common Cartridge Information Model

Figure 4.1 CC profile of CP v1.2-
Root.

Figure 4.2 CC profile of CP v1.2 -
Resources.

Figure 4.3 CC profile of CP v1.2 -
Organizations.

4.4 Content Packaging

4.4.1 Overview

The Common Cartridge builds upon a profile
of Content Packaging. This profile is constructed using the
CPv1.2 schema, but currently only harnesses those features
previously available in CPv1.1.4. The following provides an
overview of the basic usage of IMS Content Packaging

4.4.1.1 Manifests and Sub Manifests

In the Common Cartridge profile, all
content will be captured in a single IMS manifest. Sub manifests
will not be used.

4.4.1.2 Meta-data

" LOM Metadata (restricted to DC elements for the cartridge level meta-data) will be used to capture meta-data.

4.4.1.3 Organization

The Organization will be used to represent
the Common Cartridge Folder content type. See the discussion on
representing the Common Cartridge Folder Type for the additional
profiling applied to this data.

4.4.1.4 Resources

In general, all additional data required to
describe a piece of content which is included in the cartridge,
will be included as a separate file and referenced from a
Resource object

The Resource Type characteristic object
will be used to identify the type of the external data. New
resource types will be defined for each type of content included
in the scope of CC. The format of these types should follow the
guidelines defined in [CP, 07].

Where a particular content instance
requires multiple resource files of different types to describe
itself, these should be included as separate resource elements
with a <dependency> element linking them. Resources of
different types should not be bundled together under a single
<resource> element. E.g., the image files required by a QTI
resource should not be directly referenced as <file>
elements under the resource of type
`imsqti_xmlv1p2/imscc_xmlv1p0/assessment'. They should be
included under a separate web content resource element.

The specifics of using the Resource object
to represent different types of learning content are described
below.

4.4.2 Manifest

Manifest object may not contain child
Manifest objects.

The version characteristic object (i.e,.
version=`IMS CP 1.2') for the Manifest is prohibited in the
Common Cartridge profile to avoid confusion with the Common
Cartridge version number, which by implication, uniquely
identifies the version of Content Packaging adopted.

4.4.3 Folder Content Type

The folder content type described by the CC
requirements represents a structural/presentation based approach
to organizing content.

The folder does not imply containment in
the sense that a Windows file system folder implies containment
(i.e., you delete the folder, you delete everything it
contains).

You cannot use the folder name within file
path based semantics to reference content referenced by the
folder.

A distinct Learning Application Object can
be referenced multiple times (both within a single folder and
across folders). If a particular LMS cannot support this multiple
referencing it may choose to make a copy of the Learning
Application Object.

The following describes how the folder
content type is represented.

4.4.3.1 Usage of Organizations object

The folder content type is represented by
the IMS Organizations container object type. A Common Cartridge
may have a single Organization or no Organization.

The Default characteristic of the
Organizations object is prohibited as it has no meaning in Common
Cartridge.

4.4.3.2 Usage of Organization object

A Common Cartridge may have a single
Organization or no Organization.

The Organization object must contain a
Structure characteristic object with the value
"rooted-hierarchy".

An Organization object may contain a Title
value object. This can be used at the discretion of the LMS
taking into account how the LMS renders the organization. For
example, if the LMS renders the organization as a Learning Module
then the Title of the organization could be used as the title of
the module. If the LMS renders the organization as a set of
folders below the existing course, then the Title would probably
not be used.

<organizations/>

Or

<organizations>

<organization identifier="Org1" structure="rooted-hierarchy">

<title>Mathematics Volume III</title>

<item>... </item>

</organization>

</organizations>

4.4.3.3 Root Folder

A cartridge with a folder Organization
should always be rooted on a single Item container object. It is
not permissible to have two sibling Item containers below the
Organization. The root Item container object just represents the
root node of the Organization tree and has no other semantic or
presentational meaning. It must not contain a Title value object,
e.g., the following is valid:

<organization identifier="Org1" structure="rooted-hierarchy">

<item>

<item>

...

</item>

</item>

</organization>

The following are not valid:

<organization>

<item>

...

</item>

<item>

...

</item>

</organization>

<organization>

<item>

<title>some text</title>

</item>

</organization>

4.4.3.4 Usage of Items

An Item container object type either
represents a folder or a link to a Learning Application Object
resource from a folder.

Parameters characteristic object of Item is
not supported by CC.

Every Item object with the exception of the
root Item must contain a Title object.

4.4.3.5 Item Object Representing
Folder

An Item object which represents a folder is
indicated by the absence of an IdentifierRef characteristic
object.

4.4.3.6 Item Object representing Learning
Application Object Link

An Item object representing a link to a
Learning Application Object must contain an IdentifierRef
characteristic object which references the Resource object
describing the linked content.

Learning Application Object Item objects
may be nested by folder Item object but may not nest other folder
or Learning Application Object Item objects.

It is valid for two Learning Application
Object Item objects to reference the same Resource object. This
is consistent with the idea of the folder references equating to
usage rather than containment links.

4.4.4 Cartridge Web Content Type

Cartridge web content represents web
content that may be referenced by any Learning Application Object
in the cartridge.

Cartridge web content is represented as a
Resource object.

It may be directly referenced from a folder
Item object.

The characteristic object Type must be the
value `webcontent'.

If a cartridge web content resource is
linked from a Learning Application Object link Item object it
must have an Href characteristic object which represents the
launchable resource.

4.4.5 Associated Content Type

Associated content represents web content
that is scoped to a particular resource.

Associated content is represented as a
Resource object.

It may be directly referenced from a folder
Item object.

The characteristic object Type must be the
value
`associatedcontent/imscc_xmlv1p0/learning-application-resource'

If the associated content resource is
linked from a Learning Application Object link Item object it
must have an Href characteristic object which represents the
launchable resource.

The Resource object must contain a single
File object which references the Web Link descriptor XML file
which conforms to the http://www.imsglobal.org/xsd/imswl_v1p0
schema (see below).

The Resource object must not contain
Dependency child objects.

4.4.8 Assessment Content Type

Represented as a Resource object.

It may be directly referenced from a folder
Item object.

The characteristic object Type must be
`imsqti_xmlv1p2/imscc_xmlv1p0/assessment'.

The Resource object Href characteristic
object is prohibited.

The Resource object must contain a single
File object which references the QTI XML file. This file must
conform to the IMS CC profile of the QTI 1.2.1 schema which is
http://www.imsglobal.org/xsd/ims_qtiasiv1p2.

4.4.9 Question Bank Content Type

Represented as a Resource object.

It must not be directly referenced from a
folder Item object.

If a question bank is included in a cartridge, then it appears as a resource in te imsmanifest, but it is not included in the organization and reference to the question bank or its question items by any Learning Applicatio Object is prohibited.

Access to te question bank is restricted to the instructor, to whom it is provided as a rsource for constructing customized assessments.

How the LMS makes the question bank available to an instructor is undefined.

The characteristic object Type must be
`imsqti_xmlv1p2/imscc_xmlv1p0/question-bank'.

The Resource object Href characteristic
object is prohibited.

The Resource object must contain a single
File object which references the QTI XML file. This file must
conform to the IMS CC profile of the QTI 1.2.1 schema which is
http://www.imsglobal.org/xsd/ims_qtiasiv1p2.

4.4.10 Common Cartridge Authorization

Cartridges support authorization at two
levels: either the whole cartridge can be protected or individual
resources can be protected.

Authorization information is specified at
two levels within the cartridge information model.

The overall authorization requirements are
specified using the Authorizations object which is an extension
to the Manifest object. If the authorizations object is not
present, no authorization is required. If the authorizations
object is present it must declare Common Cartridge Authorization
first, possibly in addition to other authorization
mechanisms.

If authorization is applied to individual
resources within the cartridge rather than the cartridge as a
whole, this can be specified using the Protected characteristic
which is an extension characteristic applied to the Resource
object.

Import authorization is only applicable at
the cartridge level.

If import authorization is specified and it
is not granted, then no part of the cartridge should be imported,
including resources and files.

Access authorization only applies to
resources contained within a package.

If access authorization is specified at the
cartridge level it cascades down to the resources but not to any
files contained within those resources.

If access authorization is specified for a
resource, it covers only access to the resource itself but does
not cover access to files contained within the resource.

When access authorization is specified for
a resource, all non-management access points to that resource
within a system need to check that authorization.

Management of resources after a cartridge
has been imported is beyond the scope of this authorization
scheme, the authorization only applies to accessing the resource
in the cartridge player.

See below for further definition of the
Authorization object information model.

4.5 LOM Metadata

4.5.1 Cartridge Metadata

The Common Cartridge must be described at
the manifest level using meta-data according to the Common
Cartridge profile of the IEEE LOM (loose binding) [IEEE LOM, 05]
which describes the range of a mapping from the core elements of
the Dublin Core specification v1.1 [DC, 03] to IEEE LOM. This
application profile is restrictive. It uses the namespace
http://ltsc.ieee.org/xsd/imscc/LOM which differs from the IEEE
LOM namespace by the insertion of imscc. In contrast, meta-data
for resources (see below) need to use the original IEEE LOM
namespace.

The meta-data element as well as its schema
and schema version element are required at the manifest level.
They must be expressed as follows.

<metadata>

<schema>IMS Common Cartridge</schema>

<schemaversion>1.0.0</schemaversion>

... metadata according to Common Cartridge profile of IEEE LOM ...

</metadata>

The usage of meta-data at other places in
the common cartridge is not restricted. This may change in future
versions of the specification.

It should be noted that there are some
differences between IMS Meta-data and IEEE LOM with respect to
binding. Since the CC meta-data is based upon the IEEE LOM
binding, it is not order sensitive.

Any media player, codec, browser plug-in or
operating system requirements for the cartridge content must be
declared in the cartridge-level meta-data description. Each entry
should include details of the tool/product name, version number,
supplier name and the URL for their website. Such requirements
must be entered in the description element for the cartridge as
free text.

4.5.1.1 Mapping of Dublin Core Elements to
LOM Metadata Elements:

Table 4.2 Mapping of Dublin Core to IEEE
LOM.

Dublin Core Element

IEEE LOM Element

Value Type (see documentation of IEEE
LOM)

dc:contributor, dc:creator,
dc:publisher

lifeCycle.contribute.entity with
appropriate value of lifeCycle.contribute.role

The value held by the Entity element shall
be a character string literal that is the canonical lexical

representation of a valid vCard as defined
in IETF RFC 2426:1998.

dc:coverage

general.coverage

LangString

dc:date

lifeCycle.contribute.date

YYYY[-MM[-DD[Thh[:mm[:ss[.s[TZD]]]]]]]

dc:description

general.description

LangString

dc:format

technical.format

-- A literal that is the canonical lexical
representation of a Multipurpose Internet Mail Extension

(MIME) type value from RFC 2048

-- The token non-digital

dc:identifier

general.identifier

Consists of catalog set to e.g. `ISBN' and
entry containing the actual ISBN number

in general.keyword LangString, in
classification.keyword choice of purpose, taxonPath, description,
and LangString

dc:title

general.title

LangString

dc:type

Educational.learningResourceType

Set to
"IMS Common Cartridge"

4.5.1.2 A Number of Elements of IEEE LOM
are Unused and are Therefore Prohibited:

No custom elements are allowed

interactivityType unused

interactivityLevel unused

semanticDensity unused

intendedEndUserRole unused

context unused

typicalAgeRange unused

difficulty unused

typicalLearningTime unused

description is unused in educational
context

language is unused in technical context, it
is used only in general context

structure is not used

aggregationlevel is not used

version is not used

status is not used

metaMetadata are not used

annotation is not used

No size information

location not used

requirements not used

installationRemarks unused

otherPlatformRequirements unused

duration unused

4.5.2 Roles Meta-data

If meta-data is applied to resources, then
it must be based on IEEE LOM. In particular, it must use the IEEE
LOM namespace http://ltsc.ieee.org/xsd/LOM.

There are situations where resources may
need to be specified within the organization, but should not be
made visible in player mode upon default import of the cartridge.
One such situation is the inclusion of instructor manuals, lesson
plans, instructor notes and solution files that should only be
visible to instructors. In other situations, publishers may wish
to provide additional, optional resources that may be selectively
released to students by the instructor at some later date. In
both cases, there is a need to indicate where the resources
should appear within the organization even though the resources
are not initially visible to learners in the cartridge player.
These resources must be made visible in cartridge editors so that
the settings may be modified when and if appropriate.

To meet these needs, the common cartridge
applies optional "roles" meta-data associated with the resource
in the manifest file. If not present, then the default behavior
is that the resource would be viewable by all users. If present,
then it declares the roles for which the resource would be
viewable. The roles for which a specific resource is released are
declared in the resource meta-data as the content of the
elements:

lom/educational/intendedEndUserRole/vocabulary/value

Currently, the only supported roles are
`Learner' and `Instructor' defined in the vocabulary:

IMS_GLC_CC_Rolesv1p0

The context for which these values are
applicable must be identified in:

lom/educational/context/value

Currently, the only supported context is
`higher education'. For example:

<lom:lom>

<lom:educational>

<lom:context>

<lom:source>LOMv1.0</lom:source>

<lom:value>higher education</lom:value>

</lom:context>

<lom:intendedEndUserRole>

<lom:vocabulary>

<lom:source>IMSGLC_CC_Rolesv1p0</lom:source>

<lom:value>Learner</lom:value>

<lom:value>Instructor</lom:value>

</lom:vocabulary>

</lom:intendedEndUserRole>

</lom:educational>

</lom:lom>

4.6 Authorization

The authorization components of the Common
Cartridge are designed to support the requirements of the
Authorization Web Service as described in IMS Common Cartridge
Authorization Web Service [CC, 08b].

However, they also need to contain
sufficient information to support legacy authorization mechanisms
as it is not expected that all LMSs and publishers will
immediately move to using the Web Service, because their current
business model is tied to the existing mechanisms.

The authorization model supports the
following concepts:

Requiring authorization on cartridge
import

Requiring authorization on cartridge
usage

Requiring authorization on usage of
specific resources in the cartridge

Concepts 2 and 3 are mutually exclusive,
i.e., a cartridge can either specify that all resources in the
cartridge are protected or just some resources in the cartridge
are protected.

The mechanism by which the authorized
access to particular resources is enforced by the LMS is not
defined by the profile. How the `challenge' mechanism is
integrated into the user experience will be determined by the
implementation of the LMS. For example, an LMS could challenge
for authorization when a user accesses a course that contains any
protected resources. Or alternatively, an LMS could just
challenge when a user tries to access a protected resource in the
context of a course. In some cases this is not easy to do. E.g.,
if an HTML page uses a protected image, it may not be easy to
incorporate a challenge mechanism seamlessly into the display of
the HTML page. An LMS could employ some kind of redirection
mechanism or return an image requesting user to authorize
etc.

4.6.1 Specifying the Authorization
Level

The authorization requirements are
specified in the manifest as an IMS extension.

If the authorizations element is omitted
the cartridge is assumed to be open access. All authorization
mechanisms declared in the cartridge must provide the same level
of access which has been declared in the authorizations
object.

access - Determines whether authorization
must be established when cartridge content is accessed by a
learner. Valid values are `cartridge' which means all cartridge
resources are protected or `resource' which means only resources
which are specifically flagged as protected require
authorization.

import - Determines whether authorization
must be established when cartridge is imported into LMS

cartridgeId - Global unique identifier for
this cartridge

webservice - The address of the web service
that supports the IMS Common Cartridge Authorization Web Service
[CC, 08b]. If authorization is required, then this element must
be present and reference a valid authorization web service.

4.6.1.2 Protecting Individual
Resources

If the cartridge access type is set to
`resource' then the individual resources which need to be
protected are specified by adding the `Protected' characteristic
object to each resource.

4.9 QTI

4.9.1 Overview

A Common Cartridge may contain either/both
of two Learning Object Resource types that are based on the CC
QTI Profile: Assessments and Question Banks. Generally
Assessments are meant to represent an ordered question set and
may include optional attributes that apply to the set as a whole.
A CC Question Bank refers to a QTI Object Bank, constrained to
hold just those question types supported in the CC profile.
Assessments should employ the <assessment> QTI element (see
section Assessments vs. Object Banks directly below). Question
Banks are meant to represent unordered sets of questions with no
associated attributes applying to the set as a whole (though
meta-data is permitted). Question banks should use the
<objectbank> QTI element. In addition, question banks
should have no representation in the organizations section of the
manifest and if used, only one question bank can be present in a
cartridge.

<questestinterop> is the root element
for all CC QTI documents. Directly inside this will be either an
<assessment><section> or <objectbank> structure
as described in the next section.

The $IMS-CC-FILEBASE$ token may be used in
any portion of questions, answers or feedback. It is intended to
help identify paths that reference media files that are required
by the assessment and are included in the common cartridge. If
the files are not moved after extraction, the path following the
token should be the same directory that contains the qti file
itself. The token should ALWAYS be included when making relative
references to other files so that import engines can correctly
handle any required path translations. Elements or multi-element
constructs other than those covered explicitly below are
prohibited.

4.9.1.1 Assessments vs. Object Banks

Assessments are represented with a single
<assessment> element with required ident and title
attributes and optional language attribute. The
<assessment> element may contain an optional
<presentation_material> element to represent information to
be displayed prior to a student launching the assessment.

A <qtimetadata> element can be
present where CC specific meta-data elements are allowed within
<qtimetadatafield> structures as follows:

In addition to the optional
<presentation_material> and <qtimetadatafield>
elements the <assessment> element must contain exactly one
<section> element with a required ident and an optional
title attribute. The <section> element contains one or more
<item> elements only.

Object banks are represented as a single
<objectbank> element which can contain one or more
<item> elements only.

4.9.1.2 Item

<item> elements represent individual
questions in assessments or object banks (i.e. question banks).
There is a required ident attribute and an optional title
attribute which can be used when providing editors with question
lists for selection or editing. It is not presented when question
is rendered in the assessment.

Corresponds to the six supported question
types. Can be: cc.mutliple_choice.v0p1,
cc.mutliple_response.v0p1, cc.true_false.v0p1, cc.fib.v0p1,
cc.pattern_match.v0p1, or cc.essay.v0p1

cc_question_category

A single keyword value

cc_weighting

cc_weighting specifies the preferred points
value for the question. This is useful because the scoring
variables are normalized to percentage-based values between 0 and
100. Additionally, this allows for points possible to be
specified for manually graded items such as essay questions.

Must be an integer value 0 - 99 if
provided. Otherwise a default of 1 is assumed.

qmd_scoringpermitted

Yes (Because there is no automated scoring
for essays, we use standard qmd meta-data to indicate the item is
manually scored.)

qmd_computerscored

No (for essays)

4.9.1.4 Presentation

The <presentation> element contains
elements for representing the question text and responses as
presented to the student.

A <material><mattext> structure
directly inside the <presentation> element is used for the
question text. The question text may be presented in either plain
text or html format. If the html format is used, the mattext
element must have a texttype attribute with a value of
"text/html". If plain text is used, the texttype value of
"text/plain" is optional as this is the default. Regardless of
the format, the question text must occur within a CDATA
section.

Multiple_choice, multiple_response, and
true_false questions use a <response_lid> element to
contain the individual answers. There is a required ident
attribute which should be of the form response_# to make
processing easier, and an rcardinality attribute which should be
set to Single for multiple_choice and true_false questions and
Multiple for multiple_response questions.

The <response_lid> element contains a
single <render_choice> element with a shuffle (Yes/No)
attribute to indicate whether or not scrambling of answer choices
is allowed.

The <render_choice> element contains
one or more <response_label> elements with a required ident
attribute. The < response_label > elements contain
<material><mattext> structures holding the text of
the individual answers. Response.rshuffle is not supported
here.

Fib and essay questions use a
<response_str> element instead of <response_lid> with
a required ident attribute which should be of the form response_#
to make processing easier. The <response_str> element
contains a single <render_fib> element. The rows attribute
must be set to 1. For fib questions the columns attribute may be
set any positive integer but may be ignored.

4.9.1.5 Resprocessing

<resprocessing> is a direct child of
the <item> element and is used to indicate correct answers
and response scoring.

<resprocessing> should include an
<outcomes><decvar> structure that sets
varname="SCORE".

<respcondition> elements are used to
set the value of SCORE appropriately for each response, and to
identify any <itemfeedback> (see next section:
Itemfeedback) elements that are applicable. A <respcondition
continue="Yes"> can be used for general feedback to be
provided unconditionally.

A <setvar action="Set"
varname="SCORE"> element is used inside a
<respcondition> element to set the score. With simple
multiple choice only one correct answer is allowed and it should
set SCORE to 100. All other answers should set SCORE to 0. With
multiple response only all or nothing scoring is supported.

The <conditionvar> element is used to
establish the conditions for each scoring possibility. Simple
multiple choice will use a structure like <varequal
respident="response_1">answer_1</varequal>.

Fill-in-the-blank questions are not case
sensitive on grading as indicated by setting the case attribute
to "No" in the <varequal> element. Pattern match questions
may optionally be case sensitive by setting case="Yes", but the
default is NOT case sensitive. To check if a string is contained
anywhere in the response we use the varsubstring condition which
again may or may not be case sensitive, as follows:

There should be a <displayfeedback>
element contained within the <respcondition> element for
feedback appropriate to the response. Feedback elements may be
feedback for specific answers or feedback for all
correct/incorrect answers, as determined by the conditionvar
case. However if any feedback is specified, both types of
feedback (answer level and correct/incorrect) are required.

4.9.1.6 Itemfeedback

<itemfeedback> elements with required
ident attribute, corresponding to any references placed in
<respcondition> elements, are used to define the feedback
for each case. Feedback text is contained in
<material><mattext> structures.

General feedback is given as an
unconditional feedback with continue flag on for further
processing:

<respcondition continue="Yes">

<displayfeedback feedbacktype="Response" linkrefid="general_fb" />

</respcondition>

Feedback can be attached to individual
responses as follows:

<respcondition>

<conditionvar>

<varequal respident="response_1">answer_1</varequal>

</conditionvar>

<setvar action="Set" varname="SCORE">0</setvar>

<displayfeedback feedbacktype="Response" linkrefid="answer_1_fb" />

<displayfeedback feedbacktype="Response" linkrefid="incorrect_fb" />

</respcondition>

Note that answer-specific and
correct/incorrect feedback must be provided together, or not at
all. If one is present, the other must be also.

Hints can be represented as follows:

<itemfeedback ident="hint">

<hint>

<hintmaterial>

<material>

<mattext texttype="text/html"><![CDATA[This is a hint]]></mattext>

</material>

</hintmaterial>

</hint>

</itemfeedback>

Essay questions can indicate sample answers
as follows:

<itemfeedback ident="solution">

<solution>

<solutionmaterial>

<material>

<mattext texttype="text/html"><![CDATA[here is the sample solution]]></mattext>

</material>

</solutionmaterial>

</solution>

</itemfeedback>

4.9.2 Further Element/Attribute
Restrictions for Common Cartridge

The setvar element supports an action
attribute with values of Add, Set, and Subtract. In Common
Cartridge, only Set is allowed.

The MaterialSelection selection should only
allow the mattext element. In addition the texttype attribute
should only allow values of text/html and text/plain and the
element text must be wrapper in CDATA. Additional attributes are
not allowed.

The rcardinality attribute on the
response_lid and response_str elements only allow values of
Single and Multiple. The value Ordered is not supported.

The rtiming attribute on the response_lid
and response_str elements is not supported.

The render_fib element allows many
attributes.

1. encoding - "The coding to be used for
the text. The default value of UTF-8 is assumed. This attribute
is not allowed.

2. charset - "The character set that is to
be used to represent the text string. Default value is ascii-us.
This attribute is not allowed.

3. rows - The number of rows available for
the data entry is optional.

4. columns - The number of columns
available for the data entry is optional.

5. maxchars - The maximum number of
characters available for the data entry is optional.

6. Prompt - "The type of prompt presented
to the participant in which the FIB data is to be entered. This
is an enumeration with values of Box, Dashline, Asterisk, and
Underline. Default value is Box. This attribute is not allowed as
the display format is determined by the LMS.

7. fibtype - "The type of data expected.
This is an enumeration with values of String, Integer, Decimal,
Scientific, and Boolean. This is restricted to the default value
of String. All other values are prohibited.

8. minnumber - "The minimum number of
responses that must be supplied by the participant. This
attribute is prohibited. Only one response is allowed.

9. maxnumber - "The maximum number of
responses that can be supplied by the participant. This attribute
is prohibited. Only one response is allowed.

The render_fib element is prohibited from
having any children.

The flow element is not allowed.

4.9.3 Root

Figure 4.4 CC profile of QTI v1.2.1 -
Root

4.9.4 Section

Figure 4.5 CC profile of QTI v1.2.1 -
Section

4.9.5 Common

Figure 4.6 CC profile of QTI v1.2.1 -
Common

4.9.6 Assessment

Figure 4.7 CC profile of QTI v1.2.1 -
Assessment

Common Cartridge supports only one role of
assessment which maps to the IMS concept of `Examination' (as
defined by the QTI meta-data attribute `qmd_assessmenttype').

An assessment must contain a single section
which contains all questions delivered by the assessment.
Multiple sections and references to questions in an object bank
are not supported.

An assessment does support the use of a
number of meta-data attributes which can carry additional
delivery information about the assessment such as maximum
attempts and time limit. These are defined in the profile.

4.9.7 Item

Figure 4.8 CC profile of QTI v1.2.1 -
ItemGeneral

Figure 4.9 CC profile of QTI v1.2.1 -
Item

Figure 4.10 CC profile of QTI v1.2.1 -
ItemRender

Figure 4.11 CC profile of QTI v1.2.1 -
ItemResponse

4.9.8 Material

Figure 4.12 CC profile of QTI v1.2.1 -
Material

4.9.9 Questions

The Common Cartridge supports profiles of
the following question types:

Multiple Choice (Single Response)

Multiple Choice (Multiple Response)

True/False

Essay

Simple Fill in the Blank - single response
box with single correct answer that is processed as an exact
match

The profiles for each of these question
types describe how they support:

feedback

hints

sample solutions

relative scoring

In addition, questions support a number of
meta-data attributes which describe:

a suggested weighting for the question in
the assessment

a category for the question.

Instances of these questions may be
included in an assessment or a question bank.

CC supports both Yes/No and Distractor
feedback from QTI. Platforms must support one or the other,
cartridges can either omit or must provide both.

Cartridges can include QTI questions
without any feedback. If feedback is offered, then the question
must include both Yes/No and distractor responses.

Platforms must implement either Yes/No or
distractor responses. If both are supported, then the distractor
responses will take precedence.

For full details refer to the profile
descriptions.

4.9.10 Question Bank

Figure 4.13 CC profile of QTI v1.2.1 -
Objectbank.

The CC question bank profiles the use of
the QTI object bank. A question bank represents a collection of
questions that are associated with a particular learning context,
but not used within it. The question bank allows for the exchange
of questions to a target LMS. Both the representation of a
question bank, and how questions are utilized once the cartridge
has been imported into the LMS are LMS specific. Assessments
within a package cannot reference questions contained within the
question bank.

The behavior of an LMS in handling question
banks is undefined.

4.10 Vocabularies

Vocabularies refer to a set of string
constants used to specify pre-defined values for meta-data
elements. Typically these value sets are specified by the
document that defines the meta-data element, such as the IEEE
Learning Object Metadata or Dublin Core standards. Common
Cartridge meta-data elements may extend or replace vocabularies
with new sets that describe the content included in the
package.

For example, the lifeCycle.contributor.role
element may be specified to include values from the following
set:

student

instructor

administrator

which might be expanded to include:

designer

reviewer

Where meta-data vocabularies are extended
or replaced for use in Common Cartridge descriptions, an IMS
Vocabulary Definition and Exchange (VDEX) document is required to
define the new or extend vocabulary. See
http://www.imsglobal.org/vdex/index.html for information on the
IMS-VDEX-1.0 specification.

Common Cartridge vocabularies are fixed and
may not be replaced, extended, or modified.

5. Implementation Guidelines and Best
Practices

5.1 General Best Practices

A convention could be utilized based on
some form of UID to prevent collisions with user generated web
content folder names. Additionally, a subdirectory may be created
to contain all Learning Application Object directories to further
reduce the risk of collisions between Learning Application Object
directories and those in the web content.

5.1.1 Extensions to Resources
Meta-data

Compliant systems must at least tolerate
any structure attached to extension points.

5.1.2 Accessibility

Extensions for accessibility supported in
Content Packaging v1.2 have been incorporated into the schema for
Common Cartridge v1.0. However, whilst these extensions are
provided for use by those wishing to provide accessibility
features, their use and implementation is not mandated for
general use and they will not be addressed in any conformance
tests developed.

For guidance on use of the accessibility
extensions, see the Content Packaging v1.2 specification.

5.2.4 Relative Paths

The following table illustrates all valid
relative file reference scenarios for each resource.

5.2.4.1 Valid Relative File References

Resource

Valid Relative
References

Resource 0001

Resource 0001, Resource 0002

Resource 0002

Resource 0001, Resource 0002

Resource 0003

Resource 0001, Resource 0002, Resource
0004

Resource 0004

Resource 0001, Resource 0002, Resource
0004

Resource 0005

Resource 0001, Resource 0002

Resource 0006

Resource 0001, Resource 0002, Resource
0007

Resource 0007

Resource 0001, Resource 0002, Resource
0007

The following three tables illustrate the
required relative path to access another file in the root
directory of another resource. An X in a box indicates that a relative
reference to
files in that resource are not allowed.

5.2.4.2 Relative Paths for Sample 1

Relative path to file in
root of resource #

Resource

0001

0002

0003

0004

0005

0006

0007

0001

./

./

X

X

X

X

X

0002

./

./

X

X

X

X

X

0003

../

../

X

./

X

X

X

0004

../

../

X

./

X

X

X

0005

../

../

X

X

X

X

X

0006

../

../

X

X

X

X

X

0007

../

../

X

X

X

./

./

5.2.4.3 Relative Paths for Sample 2

Relative path to file in
root of resource #

Resource

0001

0002

0003

0004

0005

0006

0007

0001

./

./

X

X

X

X

X

0002

./

./

X

X

X

X

X

0003

../../

../

X

./

X

X

X

0004

../../

../../

X

./

X

X

X

0005

../../

../../

X

X

X

X

X

0006

../../

../../

X

X

X

X

X

0007

../../

../../

X

X

X

./

./

5.2.4.4 Relative Paths for Sample 3

Relative path to file in
root of resource #

Resource

0001

0002

0003

0004

0005

0006

0007

0001

./

./

X

X

X

X

X

0002

./

./

X

X

X

X

X

0003

../../content/

../../content/

X

./

X

X

X

0004

../../content/

../../content/

X

./

X

X

X

0005

../../content/

../../content/

X

X

X

X

X

0006

../../content/

../../content/

X

X

X

X

X

0007

../../content/

../../content/

X

X

X

./

./

5.3 Content & Assessment Issues

5.3.1 Course Essentials

Provide comprehensive information about the
course and its content, including, but not limited to:

Full book title (including edition). If
there is no corresponding book, provide the course title.

Avoid the use of glyphs, such as curly or
typographer's quotation marks, which may not render properly in
some platforms. Unfortunately, curly quotes is a default setting
in MS Word. When this feature is active, straight quotation marks
are automatically changed to curly quotes while typing. Disable
it when authoring content for the Common Cartridge.

5.3.2.2 Keep it Small!

Always keep course size in mind when
designing and building a course. If any modules or features are
repeated throughout the course, place them in a section that can
hold these common elements. Doing this can dramatically cut down
on the size of the cartridge. Optimally, a course should not be
larger than 100 MB. Better yet, whenever possible, put larger,
commonly-used files on a server, external to the course, and link
to them there.

5.3.2.3 Use External Servers for Large and
Commonly Used Files

Large files (such as PPT, Word/Excel, PDFs,
movies and other media) generally should not be included within a
course. Anything loaded within the course will tend to enlarge
the course size and this will increase the time to download a
course. When multiple instances of a course are installed on a
server to support multiple sections, significant server space may
be needlessly consumed with redundant content. Content stored on
external servers will need to be made available to course users,
though. For publishers, this will likely mean hosting content on
a server that is globally accessible from the Internet. For a
locally-produced university course, this may mean hosting content
on a server accessible by the intended users - wherever they are,
inside or outside of the university firewall.

5.3.2.4 Avoid "Platform-Specific"
Language/Icons

Sometimes "platform-specific" language
appears in assessments and or other pages of a course. This could
be anything from instructions on how to submit a quiz for grading
to module-specific information. Avoid such platform-specific
language and/or icons in your course content.

5.3.2.5 Plan for Change

A professor can alter the look/feel of a
course within minutes of installing it on a university server, so
the design of a course should be kept clean and simple. Provide a
simple yet professional banner and icon set for the course. It
may be possible to use a generic set of icons for all
courses.

5.3.2.6 Make it Compatible

Some platforms support multiple correct
answers, while others may not. Some CMS support tutorial mode -
where questions are presented one at a time - while others may
not. Some systems may re-order questions. Some systems may
support hints or feedback, but that feedback is generally for
right or wrong answers and rarely support individualized feedback
for each specific answer. Develop questions that will work on all
platforms.

Develop assessments that the Common
Cartridge currently supports:

Multiple choice, single response

Multiple choice, multiple response

True/false

Essay

Fill-in-the-blank

Patternmatch

See the Common Cartridge specifications for
more information about the individual question types.

An assessment may include a reading, image,
hyperlink to another website, or a set of instructions at the top
of the quiz that are needed for the student to answer the
questions. Decide how to handle these questions. The information
can be included in each question, or the question can include a
link to it.

Try to keep the quizzes in a course to a
reasonable number. Otherwise, an instructor may encounter
problems when using the course gradebook.

5.3.2.7 Check it

Proofread and QA the course content against
the original source materials, ensure that all course elements
function properly, and all external resources are appropriately
available.

5.4 LMS Issues

5.5 Known Common Cartridge Issues

5.6 Future Development

It is planned to include a further Learning
Tools Interoperability resource type in CC when the LTI
specification has been finalized.

The IMS Content Packaging specification
v1.2 is to be augmented with guidance on how to namespace in
accessibility meta-data. It is intended that CC practice will
follow the same approach, hence users wishing to implement
support for accessibility should follow the CPv1.2 guidance.

The IMS CC K12 group is currently compiling
recommendations for additional features for CC required by the
K12 community. These will be considered for inclusion in the next
and subsequent releases of CC.

6. Conformance

The Common Cartridge schema which profiles
the CPv1.2 schema and the schemas which profile CC usage of LOM
Metadata v1.0 and QTI v1.2.1 have been defined using the IMS
SchemaProf tool v1.0. The tool produces a set of derived schemas,
corresponding to the CC schema and its profiled auxiliary
schemas, against which any cartridge must validate.

SchemaProf also allows the application of
additional constraints which further constrain how CC may be
used. These encompass:

Static constraints: The parameters (e.g.
file names) are fixed in the profile
(Example: imsmanifest.xml must exist at the root of the
package)

Dynamic constraints: The parameters are
taken from an instance document in the package (Example: href of
a resource must point to a QTI file

Conditional constraints: The constraint
depends on a condition
(Example: If parameter `contenttype' is `question' then attribute
`href' must point to a QTI file).

To be deemed to comply with the CC
specification, cartridges must:

Successfully validate against the CC schema
set

Satisfy all of the additional
constraints.

6.1 Cartridge Compliance

IMS GLC will distribute a self-test tool to
enable implementers to test their cartridges for compliance with
the specification. Visit http://www.imsglobal.org/cc/alliance.html to access
the latest version of the tool and its documentation.

6.1.1 Cartridge Authorization

6.1.1.1 Unprotected Cartridges

Use of CC Authorization for content
protection is entirely optional for publishers and content
providers. Therefore unprotected cartridges which meet the CC
conformance requirements can claim CC compliance.

6.1.1.2 Protected Cartridges

In addition to meeting the other
conformance requirements, protected cartridges must also meet the
following requirements in order to achieve CC compliance:

Protected cartridges must include the
standard CC Authorization meta-data. Optionally, they may also
include proprietary authorization meta-data.

The web service indicated in the standard
CC Authorization meta-data must be a fully functioning standard
CC Authorization web service.

A user with a valid license must be able to
obtain permission to access the protected resources in a
cartridge by passing a valid access code to the standard CC
Authorization web service (i.e. the referenced standard CC
Authorization service may not be used simply to block access in
the non-proprietary use case).

6.1.2 Cartridge Assessments & Question
Banks

The Common Cartridge supports profiles of
the following question types:

Multiple Choice (Single Response)

Multiple Choice (Multiple Response)

True/False

Essay

Simple Fill in the Blank - single response
box with single correct answer that is processed as an exact
match

The profiles for each of these question
types describe how they support optional features such as:

feedback

hints

sample solutions

relative scoring

In addition, questions support optional
meta-data attributes which describe:

a suggested weighting for the question in
the assessment

a category for the question.

Section 4.10 describes the use of these
features as they are supported by the CC profile of QTIv1.2.1.
Cartridge implementers wishing to use these optional features
must adhere to the CC QTI schema and cartridges will be tested
for compliance. However, it should be noted that support for
these optional features is not mandatory for CC compliant
platforms. Thus it cannot be assumed that all optional QTI
features harnessed in a cartridge will be supported by a given
platform.

6.1.3 Scope of Cartridge Tests

The self-test tool will:

Test unzipping the cartridge.

Test correctness and completeness of
references in imsmanifest.

Do XML validation of all XML files in the
cartridge using namespaces for which profiles are defined in the
CC spec (including imsmanifest and all QTI files).

Report XML files in the package which were
not checked (either since they did not concern CC or the
namespace given was incorrect).

Do Schematron validation for all XML files
in the package for which the CC spec has defined conditional
modifications.

Enable further Content Packaging specific
tests, not currently required by the CC profile (n.b. for
inter-package references using xpointer, the test will confirm
the existence of the remote package, but will not interrogate its
content).

Add support for additional constraints as
created with SchemaProf, including:

Checking restriction of Mime types and file
size.

Validating XML files in the package against
arbitrary schemas specified in the domain profile.

Check correct use of VDEX
vocabularies.

Perform full validation against auxiliary
profiles including an assertions and constraints associated with
them.

6.1.4 Limitations of Cartridge Testing

The testing tool will ensure the presence
of appropriate media files for a learning application resource
(e.g., mpg, jpg), but not verify their internal structure.

The testing tool will not apply run-time
tests to the cartridge content.

CC requires that the cartridge meta-data
identifies any client-side players or web-browser plug-ins
required to run the content. This is expressed as free-text and
so will not be tested.

6.1.5 Cartridge Additional Constraints

Appendix C lists the schema modifications
and assertions imposed on the CC profile schema set. Appendix D
lists the schematron rules applied to candidate cartridges. Note
that these lists may be extended in the future and implementers
are advised to access the most current list from: http://www.imsglobal.org/cc/alliance.html

6.2 LMS Compliance

From an LMS perspective, the CC
specification defines:

The syntax for cartridges which a platform
must be able to successfully import.

A set of features that the LMS must be
capable of supporting at runtime.

The criteria for platform compliance
are:

Successful import of compliant cartridges
without error.

Correct runtime delivery of the content and
features defined in compliant cartridges.

Support for CC Authorization, the level of
which determines the level of compliance (namely CC or CC lite)
that the platform can claim against the CC specification.

No runtime model is defined for Common
Cartridge, this being left as an issue for the implementer and
therefore runtime behavior (in particular presentation) will
differ across platforms.

A test data set of cartridges has been
constructed for evaluating platform compliance as is described
below.

Platform vendors are required to assess
compliance by self-inspection using the available test data set
corresponding to the version of CC that they have
implemented.

6.2.1 CC Compliance

Only platforms which:

Meet the conformance requirements
identified in the CC specification and

Fully implement the CC Authorization
service

can claim CC compliance.

6.2.2 CC Lite Compliance

Full implementation of the CC Authorization
service is not a requirement for `CC lite' compliance. However,
only platforms which meet the conformance requirements of the CC
specification and which either:

Routinely deny import of protected
cartridges and deny any access to protected content, or

Are able to process the additional
proprietary authorization information included in a
cartridge

can claim `CC lite' compliance. It should
be noted that systems which only support proprietary
authorization will not be able to run cartridges which only
include the open CC Authorization meta-data, hence their
designation as being `CC lite' compliant.

All systems must at least respect the
implied restrictions placed on content as indicated by the CC
Authorization meta-data that may exist in a cartridge. If a
system that does not implement the CC Authorization service
encounters a common cartridge that includes CC Authorization
meta-data, the system must not import the cartridge. Instead the
system should abort the import of the cartridge with an
indication of the reason provided through an appropriate
mechanism. If the import operation is interactive, a message
should be displayed directly to the user. If the import operation
is a batch or automated process, notification should be logged
with any audit data provided.

The CC Authorization service is intended to
provide an alternative to existing proprietary models for
controlling access to content via an access code redemption
model. However, the Common Cartridge specification also allows
the inclusion of additional proprietary authorization information
so that proprietary authorization models may be implemented
alongside the standard CC Authorization model.

6.2.3 Cartridge Assessments & Question
Banks

Section 4.9 describes the use of optional
QTI features as they are supported by the CC profile of
QTIv1.2.1. LMS platforms must support the six basic question
types, but it is not mandated that an LMS platform must support
any of these optional features. Thus when a compliant platform
encounters such optional features included in a cartridge, the
platform is at liberty to ignore any which it does not
implement.

The IMS QTI specification offers great
flexibility for implementers to select those features they wish
to support or are required by their users. Given the present
variability in existing QTI implementations, it is not feasible
at this stage to mandate that all platforms must support all
optional features associated with the supported question
types.

6.2.4 LMS Testing

The LMS vendor will conduct a
self-administered test, based on the CC test data set. The
platform must correctly import, store and deliver all of the
examples in the test data set.

The following guidelines are offered for
testing import of Common Cartridges into an LMS:

On import LMS should confirm that package
has imported properly or that there were errors importing the
package. Error messages should attempt to direct the user to the
problem within the package such as identify a resource that could
not be located within the package.

If the package requires import
authorization, the LMS should prompt the user for an
authorization key and confirm the authorization through the
specified web service. If the LMS does not support authorization,
the package should be rejected.

Verify that each item listed in the
manifest appears in the content area for the course. The browsing
structure should match that in the manifest.

Test each media link to confirm that it
responds properly. Web content links should direct you to the
appropriate site. References to content local to the package
should a) find the referenced media and b) open the media with
the appropriate device. (It is appropriate to attach a style
sheet for html content local to the package. These style sheets
should be respected in the display of content.)

If authorization is required at the content
level, confirm that the LMS directs the user through the
authorization process (same as above) prior to allowing access to
the content. Authorization is not required for administrators or
instructors. Again, if authorization is not supported, access to
the content should be denied.

Assessment items: Import will vary
depending on the LMS. However, the LMS should support any
assessment option (time limit, feedback, question type) that is
available for native content.

Verify that discussion topics import into a
discussion forum appropriate for the course. A new topic should
be created using the <text> in the xml as the prompt. Check
each attachment link. Post to the topic as a test.

6.3 Test Data Set

A test data set of cartridges is available
to members of the CC Alliance to enable self-testing of platforms
for CC compliance. The test data set is comprised of two sets of
example cartridges:

Valid cartridges which exercise the scope
of the features supported in the Common Cartridge.

Known error cartridges which provide
coverage of errors liable to occur in cartridges.

The full set of files that define the
Common Cartridge Application Profile are available as
ccv1p0.zip.

The following files are located in the root
directory of the zip-file:

imscp_v1p2.xsd - the original xsd for
Content Packaging v1.2

imscc_c1p2maeV0p15.xml - defines the
modifications made to the CPv1.2 xsd in creating the CC
profile.

index.xml

license.html

There are also a number of subdirectories
off the root, each containing a zip-file of an auxiliary profile
as follows:

/profile_0/imscc_a.zip

Authorization profile

/profile_1/imscc_e.zip

Content Packaging extensions profile

/profile_2/imscc_m.zip

Cartridge meta-data IEEE LOM (loose
binding) profile

/profile_3/imscc_mR.zip

Roles meta-data IEEE LOM (loose binding)
profile

/profile_4/imscc_q.zip

Question & Test Interoperability
profile

/profile_5/imscc_w.zip

IMS weblinks

/profile_6/imscc_d.zip

Discussion topics profile

These profiles are provided for inspection
with the IMS SchemaProf tool.

Finally, the /derived_schema subdirectory
contains the profiled XML schemas and Schematron rules. Only the
files within this directory are used by the IMS Common Cartridge
Test System. The derived schemas have names of the form
_localised.xsd while the files containing the derived Schematron
rules have names ending in _constraintsDocument.scmt.

The derived data for the IMS Content
Packaging Profile is located immediately in the directory
derived_schema. The data for the auxiliary profiles are in the
subdirectories named domainProfile_0,, domainProfile_6.

The file derived_schema/config.xml maps the
namespaces specified in the Common Cartridge profile to the
locations of the derived data (i.e. below the /derived_schema
directory) defining the respective namespace.

Table B.1 Mappings in
/derived_schemas/config.xml.

Namespace

xsd Location in Schema Package

http://www.imsglobal.org/xsd/imscp_v1p1

/derived_schema/imscp_v1p2.xsd

http://www.imsglobal.org/xsd/imscc/imscp_v1p1

/derived_schema/imscp_v1p2_localised.xsd

http://www.imsglobal.org/xsd/imsccauth_v1p0

/derived_schema/domainProfile_0/
imsccauth_v1p0_localised.xsd

http://ltsc.ieee.org/xsd/imscc/LOM

/derived_schema/domainProfile_1/lomLoose_localised.xsd

http://ltsc.ieee.org/xsd/imscc/LOM/unique

/derived_schema/domainProfile_1/loose.xsd

http://ltsc.ieee.org/xsd/imscc/LOM/vocab

/derived_schema/domainProfile_1/vocab/loose.xsd

http://ltsc.ieee.org/xsd/imscc/LOM/extend

/derived_schema/domainProfile_1/extend/custom.xsd

http://ltsc.ieee.org/xsd/LOM

/derived_schema/domainProfile_2/lomLoose_localised.xsd

http://ltsc.ieee.org/xsd/LOM/unique

/derived_schema/domainProfile_2/loose.xsd

http://ltsc.ieee.org/xsd/LOM/vocab

/derived_schema/domainProfile_2/vocab/loose.xsd

http://ltsc.ieee.org/xsd/LOM/extend

/derived_schema/domainProfile_2/extend/custom.xsd

http://www.imsglobal.org/xsd/imscp_extensionv1p2

/derived_schema/domainProfile_3/imscp_extensionv1p2_localised.xsd

http://www.imsglobal.org/xsd/ims_qtiasiv1p2

/derived_schema/domainProfile_4/ims_qtiasiv1p2_localised.xsd

http://www.imsglobal.org/xsd/imswl_v1p0

/derived_schema/domainProfile_5/imswl_v1p0_localised.xsd

http://www.imsglobal.org/xsd/imsdt_v1p0

/derived_schema/domainProfile_6/imsdt_v1p0_localised.xsd

The Common Cartridge schema package defines
the file locations for the namespaced profile schemas in the file
/derived_schema/config.xml

The auxiliary profiles are situated in the
profile_0..6 subdirectories of the unzipped profile. They can be
directly loaded as zip with SchemaProf for inspection.

The derived schemas and Schematron rules
used for testing are in the subdirectory derived_schema.

/derived_schema/config.xml maps namespaces
to the locations of the derived schemas where they are
defined.

<sp:documentation category="general"
xml:lang="en">This profile of IMS Content Packaging is based
on the status of the Common Cartridge Specification as of June
30, 2008. It has been created by Ingo
Dahn.</sp:documentation>

<sp:documentation category="scope"
xml:lang="en">This profile combines profiles of IMS Content
Packaging 1.2 and IEEE LOM. Moreover the IMS Common Cartridge
Authorization Schema has been added as a profile. The IMS Common
Cartridge profile of QTI 1.2 has been added
manually.</sp:documentation>

<sp:documentation
category="explanation" xml:lang="en">An item which represents
a folder must not have subitems. This is encoded as an assertion
at item/@identifierref</sp:documentation>

</sp:annotation>

</sp:cardinality>

- <sp:assertion
subelement="./xs:attribute[@name='identifierref']">

- <sp:annotation>

<sp:documentation
category="explanation" xml:lang="en">An Item object which
represents a folder is indicated by the absence of an
IdentifierRef characteristic object. Folder Items support
unlimited nesting of other folder Items and learning object link
Items. Learning Application Resource Item objects may be nested
by folder Item object but may not nest other folder or Learning
Application resource Item
objects.(#S04)</sp:documentation>

<sp:documentation
category="explanation" xml:lang="en">The use of the isvisible
attribute of the item element is prohibited. Instead, roles
should be used to determine resources which are for instructors
only.</sp:documentation>

<sp:documentation
category="explanation" xml:lang="en">At the manifest level,
the Common Cartridge profile of IEEE LOM loose must be used,
which corresponds to unqualified Dublin
Core.</sp:documentation>

<sp:documentation
category="explanation" xml:lang="en">For the metadata at the
resource level IEEE LOM must be used. Roles of 'Learner' and
'Instructor' can be used as
'intendedEndUserRole'.</sp:documentation>

<sp:documentation
category="explanation" xml:lang="en">A cartridge with a folder
Organization should always be rooted on a single Item container
object. It is not permissible to have two sibling Item containers
below the Organization. The root Item container object just
represents the root node of the Organization tree and has no
other semantic or presentational
meaning.</sp:documentation>

<sp:documentation
category="explanation" xml:lang="en">The folder content type
is represented by the IMS Organizations container object type. A
common cartridge may have a single Organization or no
Organization. Only 'Learner Experience' resources may be included
in the <organization> hierarchy. Operational data
(authentication, cartridge-level metadata) are defined via
discrete resource types within the package. Supplemental
resources must not appear in the organization. The LMS provides a
way for the instructor/facilitator to inspect/deploy/utilize
these resources as they see fit.</sp:documentation>

<sp:documentation
category="explanation" xml:lang="en">If authorization is
applied to individual resources within the cartridge rather than
the cartridge as a whole, this can be specified using the
Protected characteristic which is an extension characteristic
applied to the Resource object. At the extension point of the
Resource.Type also the variant element of the content packaging
extension schema is allowed.</sp:documentation>

</sp:annotation>

</sp:attribute_extension>

- <sp:assertion cnd="cnd10"
subelement=".">

- <sp:annotation>

<sp:documentation
category="explanation" xml:lang="en">If a cartridge web
content or associated content resource is linked from a Learning
Application Object link Item object it must have an Href
characteristic object which represents the launchable
resource.(#S05)</sp:documentation>

</sp:annotation>

<sp:test>count(./@href)=1</sp:test>

</sp:assertion>

- <sp:assertion cnd="cnd2"
subelement=".">

- <sp:annotation>

<sp:documentation
category="explanation" xml:lang="en">For Discussion Topic
Resources the Resource object must contain a single File object
which references the Discussion Topic descriptor XML file which
conforms to the http://www.imsglobal.org/xsd/imsdt_v1p0 schema.
It must not have any href
attribute.(#S06)</sp:documentation>

</sp:annotation>

<sp:test>count(./file)=1 and
count(./@href)=0</sp:test>

</sp:assertion>

- <sp:assertion cnd="cnd3"
subelement=".">

- <sp:annotation>

<sp:documentation
category="explanation" xml:lang="en">For Web Link Resources
the Resource object must contain a single File object which
references the Web Link descriptor XML file which conforms to the
http://www.imsglobal.org/xsd/imswl_v1p0 schema. It must contain
neither Dependency objects nor an href
attribute.(#S07)</sp:documentation>

</sp:annotation>

<sp:test>count(./file)=1 and
count(./dependency)=0 and count(./@href)=0</sp:test>

</sp:assertion>

- <sp:assertion cnd="cnd7"
subelement=".">

- <sp:annotation>

<sp:documentation
category="explanation" xml:lang="en">For Assessment or
Question Bank Resources the Resource object must contain a single
File object which references the QTI XML file. This file must
conform to the IMS CC profile of QTI 1.2.1. The profile is
contained in the package of this profile as imscc_q*.xdm. The
derived schema of this QTI profile is in the package of this
profile with the name ims_qtiasiv1p2_localised.xsd. The resource
must not have an href
attribute(#S11)</sp:documentation>

<sp:condition id="cnd10"
name="Referenced Resource is Web Content or Associated Content
and is referenced from an Item">(./@type='webcontent' or
./@type='associatedcontent/imscc_xmlv1p0/learning-application-resource')
and ./@identifier =
//item/@identifierref</sp:condition>

In the CC schema package ccv1p0.zip the
zip-file /profile_1/imscc_e.zip contains the file imscc_e.xml
which documents the modifications made to the CPv1.2 extension
schema for the CC profile. The contents of the file are
reproduced below.

In the CC schema package ccv1p0.zip the
zip-file /profile_2/imscc_m.zip contains the file imscc_m.xml
which documents the modifications made to the IEEE Loose schema
for the CC Cartridge Metadata profile. The contents of the file
are reproduced below.

In the CC schema package ccv1p0.zip the
zip-file /profile_3/imscc_mR.zip contains the file imscc_mR.xml
which documents the modifications made to the IEEE Loose schema
for the CC Roles Metadata profile. The contents of the file are
reproduced below.

In the CC schema package ccv1p0.zip the
zip-file /profile_4/imscc_q.zip contains the file imscc_q.xml
which documents the modifications made to the QTIv1.2 schema for
the CC QTI profile. The contents of the file are reproduced
below.

The CC schema package ccv1p0.zip
contains the file
/derived_schema/imscp_v1p2_constraintsDocument.scmt which
documents the schematron rules applied to the CPv1.2 schema for
the CC CP profile. The contents of the file are reproduced
below.

<assert test="count(./@identifierref)=0
or count(./ims:item)=0">Assertion failed for pattern_4. An
Item object which represents a folder is indicated by the absence
of an IdentifierRef characteristic object. Folder Items support
unlimited nesting of other folder Items and learning object link
Items. Learning Application Resource Item objects may be nested
by folder Item object but may not nest other folder or Learning
Application resource Item objects.(#S04)</assert>

</rule>

</pattern>

<pattern name="pattern_5">

<rule
context="ims:manifest/ims:resources/ims:resource">

<assert test="not((./@type='webcontent'
or
./@type='associatedcontent/imscc_xmlv1p0/learning-application-resource')
and ./@identifier = //ims:item/@identifierref) or
count(./@href)=1">Error: Assertion failed for pattern_5: If a
cartridge web content or associated content resource is linked
from a Learning Application Object link Item object it must have
an Href characteristic object which represents the launchable
resource.(#S05)</assert>

</rule>

</pattern>

<pattern name="pattern_6">

<rule
context="ims:manifest/ims:resources/ims:resource">

<assert
test="not(./@type='imsdt_xmlv1p0') or (count(./ims:file)= 1 and
count(./@href)=0)">Error: Assertion failed for pattern_5: For
Discussion Topic Resources the Resource object must contain a
single File object which references the Discussion Topic
descriptor XML file which conforms to the
http://www.imsglobal.org/xsd/imsdt_v1p0 schema. Discussion Topic
resources must not contain href (#S06)</assert>

</rule>

</pattern>

<pattern name="pattern_7">

<rule
context="ims:manifest/ims:resources/ims:resource">

<assert
test="not(./@type='imswl_xmlv1p0') or (count(./ims:file) = 1 and
count(./ims:dependency)=0 and count(./@href)=0)">Error:
Assertion validation failed for pattern_7: For Web Link Resources
the Resource object must contain a single File object which
references the Web Link descriptor XML file which conforms to the
http://www.imsglobal.org/xsd/imswl_v1p0 schema.It must contain
neither Dependency objects nor an href
attribute.(#S07)</assert>

</rule>

</pattern>

<pattern name="pattern_11a">

<rule
context="ims:manifest/ims:resources/ims:resource">

<assert
test="not(./@type='imsqti_xmlv1p2/imscc_xmlv1p0/assessment') or
(count(./ims:file) = 1 and count(./@href)=0)">Error: Assertion
validation failed for pattern_11a: For Assessment resources the
Resource object must contain a single File object which
references the QTI XML file. This file must conform to the IMS CC
profile of QTI 1.2.1. The profile is contained in the package of
this profile as imscc_q*.zip. The derived schema of this QTI
profile is in the package of this profile with the name
ims_qtiasiv1p2_localised.xsd. The resource must not have an href
attribute(#S11a)</assert>

<assert
test="not(./@type='imsqti_xmlv1p2/imscc_xmlv1p0/question-bank')
or (count(./@href)=0 )">Error: Assertion validation failed for
pattern_11b2: A Question Bank Resource must not have an href
attribute. (#S11b2)</assert>

</rule>

</pattern>

<pattern name="pattern_11b3">

<rule
context="ims:manifest/ims:resources/ims:resource">

<assert
test="not(./@type='imsqti_xmlv1p2/imscc_xmlv1p0/question-bank')
or ( not(//ims:item[@identifierref]=./@identifier) )">Error:
Assertion validation failed for pattern_11b3: A Question Bank
Resource must not be referenced from an item.
(#S11b3)</assert>

</rule>

</pattern>

<pattern name="pattern_11b4">

<rule
context="ims:manifest/ims:resources/ims:resource">

<assert
test="not(./@type='imsqti_xmlv1p2/imscc_xmlv1p0/question-bank')
or
(count(//ims:resource[@type='imsqti_xmlv1p2/imscc_xmlv1p0/question-bank'])=1)">Error:
Assertion validation failed for pattern_11b4: There can be only
one Questionbank Resource in a
cartridge.(#S11b4)</assert>

<assert
test="(not(../@type='imsqti_xmlv1p2/imscc_xmlv1p0/assessment'))
or (current()/@identifierref =
/ims:manifest/ims:resources/ims:resource[@type='webcontent']/@identifier)
or (current()/@identifierref =
/ims:manifest/ims:resources/ims:resource[@type='associatedcontent/imscc_xmlv1p0/learning-application-resource']/@identifier)">Assertion
failed for pattern_14. A Resource object which is an assessment
may contain Dependency objects which reference Resource objects
with Type 'webcontent' or
'associatedcontent/imscc_xmlv1p0/learning-application-resource'.(#S14)</assert>

<assert
test="(not(../@type='imsqti_xmlv1p2/imscc_xmlv1p0/question-bank'))
or (current()/@identifierref =
/ims:manifest/ims:resources/ims:resource[@type='webcontent']/@identifier)
or (current()/@identifierref =
/ims:manifest/ims:resources/ims:resource[@type='associatedcontent/imscc_xmlv1p0/learning-application-resource']/@identifier)">Assertion
failed for pattern_15. A Resource object which is a Question Bank
may contain Dependency objects which reference Resource objects
with Type 'webcontent' or
'associatedcontent/imscc_xmlv1p0/learning-application-resource'.(#S15)</assert>

</rule>

</pattern>

</schema>

About This Document

Title

IMS Common Cartridge Profile

Editor

Kevin Riley

Co-Leads

Erik Unjhem, David Mills

Version

v1.0

Version Date

1 October 2008

Status

Final Specification v1.0

Summary

This document contains the profile
information for Common Cartridge, an open format for the
distribution of rich, web-based content.

Revision Information

16 July 2008

Purpose

This document has been approved by the IMS
Technical Advisory Board and is made available for pubic
adoption.