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.

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.

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.

# 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