IMS Logo

IMS GLC Common Cartridge Profile: Use Cases

Version 1.1 Final Specification

Date Issued: 10 January 2011

Latest version: http://www.imsglobal.org/cc/index.html

IPR and Distribution Notices

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-2011 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.

Use of this specification to develop products or services is governed by the license with IMS found on the IMS website: http://www.imsglobal.org/license.html.

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.

Table of Contents

1 Use Cases. 3

1.1 Use Case Scope.. 3

1.1.1 Affected Roles and Definitions. 3

1.1.2 High-level Use Case Scope. 3

1.2 CC Package Import.. 4

1.3 Execution of Static Content.. 5

1.4 Execution of Dynamic Content – Client-side.. 6

1.5 Execution of Dynamic Content – Server-side.. 7

1.6 Authorization.. 10

About This Document.. 12

List of Contributors. Error! Bookmark not defined.

Revision History.. 12

1 Use Cases

1.1 Use Case Scope

1.1.1 Affected Roles and Definitions

Table 1.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.

Instructional Designer

LMS course/program designer responsible for creating and maintaining online learning materials/content. Often, the same person has Instructor role.

Administrator

LMS course, program, group administrator with ownership and privileges to access and maintain administrative elements of the LMS within a particular context.

LMS

Learning Management System (LMS) -- as defined in Glossary.

Common Cartridge User Roles

1.1.2 High-level Use Case Scope

The following diagram summarizes the use cases considered for the framework:

Figure 1.1 Use Case Framework.

1.2 CC Package Import

Use Case 1

CC Package Import

Level

Summary

Primary Actor(s)

Instructor, LMS

Secondary Actor(s)

Administrator

Trigger

Instructor needs to import a cartridge to use its content either wholly or as selective, individual content modules or elements.

Preconditions

Instructor has access to a cartridge.

LMS is Common Cartridge compatible and configured to accept package imports.

Success Post-condition

Cartridge has been processed and an Instructor-defined subset of the material is installed and ready for LMS User interactions.

Failure Post-condition

Cartridge material is unprocessed.

Main Success Scenario

1. Instructor obtains a cartridge (the provisioning and acquisition processes are not defined by this specification).

2. Instructor accesses the LMS-provided tool for cartridge import.

3. LMS reads package and generates private (implementation dependent, proprietary) data structures to store the content and structure defined in the cartridge data.

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 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 .imscc file, the manifest is missing or incorrectly named) of the cartridge prevents LMS from reading the package, the mimetype file is missing.

Package is properly structured, but individual data elements are poorly formed or unsupported (see Variation 4.1, above).

1.3 Execution of Static Content

Use Case 2

Execution of Static Content

Level

Summary

Primary Actor(s)

LMS

Secondary Actor(s)

Instructor, Student

Trigger

Actor accesses LMS navigational context requiring cartridge data to be rendered.

Preconditions

Cartridge is imported into LMS, with static (HTML, image, document) resources.

Actors have LMS-defined authorization to cartridge material (e.g., context-dependent security roles).

Actors have cartridge-defined authorization to cartridge material (use case 2.3, above).

Success Post-conditions

Cartridge static content is displayed within a navigational context that preserves 1) cartridge flow and 2) LMS flow.

Failure Post-conditions

LMS-defined error message or status display.

Main Success Flow

1. Learner navigates to LMS context containing cartridge materials.

2. LMS renders both LMS defined and cartridge defined navigation elements (links, directories, tree-view, “next” option, etc.).

3. Learner activates link requiring display.

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.

1.4 Execution of Dynamic Content – Client-side

Use Case 3(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.

Failure Post-conditions

LMS-defined error state and communication to the user.

Main Success Flow

1. Student visits a Deployment Context containing a Learning Activity instance.

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).

3. LMS learning activity run-time interprets the trigger navigation request and loads/recalls/interprets from internal cache or repository the associated learning module, Learning Application Object or content element instance required.

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.

10. LMS Learning Activity run-time dismisses the viewer-player context for the completed learning module interaction.

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.

Exception Conditions

LMS cannot reference/obtain required Learning Activity learning module, Learning Application Objects and/or content elements.

Security assertion failure.

LMS Learner Activity run-time delegated viewer-player fails.

LMS Learner Activity outcome response failure.

1.5 Execution of Dynamic Content – Server-side

Use Case 3(b)

Execution of Dynamic Content – Server-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.

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.

Failure Post-conditions

LMS-defined error state and communication to the user.

Main Success Flow

1. Student visits a Deployment Context containing a Learning Activity instance.

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).

3. LMS learning activity run-time interprets the trigger navigation request and loads/recalls/interprets from internal cache or repository the associated learning module, Learning Application Object or content element instances required.

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.

9. LMS learning activity run-time dismisses the presentation context for the completed learning module.

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.

Exception Conditions

LMS cannot reference/obtain required Learning Activity learning module, Learning Application Objects, and/or content elements.

Security assertion failure.

LMS Learner Activity run-time delegated viewer-player fails.

LMS Learner Activity outcome response failure.

Use Case 3(c)

Launching Basic LTI Imported from a Cartridge (with secret)

Level

Summary

Primary Actor(s)

Cartridge Creator, Instructor, Tool Consumer (TC) User

Preconditions

The TC Administrator has received and installed the appropriate credentials for the particular TP(s) that are referenced in the cartridge.

Main Success Flow

An Instructor imports a Common Cartridge containing Basic LTI link descriptors into their context and users use the content.

1. The Cartridge Creator authors a cartridge and includes one or more Basic LTI link descriptors in the cartridge. The Basic LTI link descriptors in the cartridge contain a launch URL(s) and other data but do not contain keys or secrets.

2. The Instructor obtains the Common Cartridge and imports it into their context in the TC system.

3. When a TC User launches the Basic LTI link imported from the Common Cartridge, the TC uses the pre-configured credentials associated with the TP domain or URLs.

4. In particular, as long as the TC-wide credentials are already installed, the Instructor does not need to take any further action to launch the content beyond importing a cartridge.

Variations

A. If the preconditions are not satisfied, it is also possible to set the credentials after the cartridge import has taken place. If a launch occurs before credentials have been defined, it is the responsibility of the TP to notify the user that credentials are required.

Use Case 3(d)

Launching Basic LTI Imported from a Cartridge (no secret)

Level

Summary

Primary Actor(s)

Cartridge Creator, Instructor, Tool Consumer (TC) User

Preconditions

None.

Main Success Flow

An Instructor imports a Common Cartridge containing Basic LTI link descriptors into their context and users use the content. Note that this scenario is optional – the TC and/or TP may decide that Basic LTI launches without secrets are treated as an error.

1. The Cartridge Creator authors a cartridge and includes one or more Basic LTI link descriptors in the cartridge. The Basic LTI link descriptors in the cartridge contain a launch URL(s) and other data but do not contain keys or secrets.

2. The Instructor obtains the Common Cartridge and imports it into their context in the TC system.

3. When a TC User launches the Basic LTI link from the Common Cartridge, the TC launches the Basic LTI link with no authentication or signature information.

1.6 Authorization

Use Case 4

Authorization

Level

Summary

Primary Actor(s)

Student

Secondary Actor(s)

Instructor, LMS

Trigger

An actor requests a restricted interaction with the cartridge.

Preconditions

Cartridge is successfully installed.

Cartridge defines one or more “restricted” items (e.g., view any cartridge material vs. view specific cartridge items). The specification must define authorization categories: “on import”, “on package use”, and “on item use”. This use case is for “on package use”.

Actor has not previously been authorized.

Success Post-conditions

Actor is authorized for requested action, and the results of the authorization transaction potentially stored for future reference.

Failure Post-conditions

Actor is not authorized for the requested action.

Cartridge material is not displayed.

Main Success Scenario

1. Learner navigates to LMS representation of course populated with Cartridge material.

2. LMS checks for record of previous Learner authorization.

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 where 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.).

About This Document

Title: IMS GLC Common Cartridge Profile: Use Cases

Editor: Jeff Kahn (IMS GLC)

Version: 1.1

Version Date: 10 January 2011

Status: Final

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

Purpose: This document has been approved by the IMS Common Cartridge Accredited Profile Management Group and is made available for pubic adoption.

Document Location: http://www.imsglobal.org/cc/ccv1p1/imscc_profilev1p1-UseCases.html

List of Contributors

The following individuals contributed to the development of this document:

Name

Organization

Thor Anderson

Utah Valley University

Brent Bailey

Elsevier

Warwick Bailey

Icodeon

Jeff Bradley

Blackboard Inc.

Ingo Dahn

University of Koblenz-Landau

Jeff Kahn (editor)

IMS Global Learning Consortium

Lisa Mattson

IMS Global Learning Consortium

Chris Moffatt

Microsoft Inc.

Mark O’Neil

Blackboard Inc.

Colin Smythe

IMS Global Learning Consortium

Erik Unhjem

Pearson Education

Claude Vervoort

Blackboard Inc.

Jennifer Whiting

Florida Virtual School

Yong-Sang Cho

KERIS

Revision History

Version No.

Release Date

Comments

Final v1.0

29 January 2009

The first formal release of the CC specification.

Public Draft v1.1

9 November 2010

The Public Draft of the CC v1.1 specification.

Revised Draft v1.1

6 December 2010

Revised Public Draft of the CC v1.1 specification.

Revised Draft v1.1

24 December 2010

Document edited to only include Use Cases.

Final v1.1

10 January 2011

The Final CC v1.1 specification.

IMS Global Learning Consortium, Inc. ("IMS GLC") is publishing the information contained in this IMS GLC Common Cartridge Profile Use Cases ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.
IMS GLC makes no warranty or representation regarding the accuracy or completeness of the Specification.
This material is provided on an "As Is" and "As Available" basis.
The Specification is at all times subject to change and revision without notice.
It is your sole responsibility to evaluate the usefulness, accuracy, and completeness of the Specification as it relates to you.
IMS GLC would appreciate receiving your comments and suggestions.
Please contact IMS GLC through our website at http://www.imsglobal.org
Please refer to this as Document Name: IMS GLC Common Cartridge Profile: Use Cases
Revision: 10 January 2011