IMS Logo

IMS Shareable State Persistence Information Model

Version 1.0 Final Specification

Copyright © 2004 IMS Global Learning Consortium, Inc. All Rights Reserved.
The IMS Logo is a trademark of IMS Global Learning Consortium, Inc.
Document Name: IMS Shareable State Persistence Information Model
Revision: 18 June 2004

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 © 2004 IMS Global Learning Consortium. All Rights Reserved.

If you wish to copy or distribute this document, you must complete a valid Registered User license registration with IMS and receive an email from IMS granting the license to distribute the specification. To register, follow the instructions on the IMS website: http://www.imsglobal.org/specificationdownload.cfm.

This document may be copied and furnished to others by Registered Users who have registered on the IMS website provided that the above copyright notice and this paragraph are included on all such copies. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to IMS, except as needed for the purpose of developing IMS specifications, under the auspices of a chartered IMS project group.

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. Specification Overview
     1.1 Rationale
           1.1.1 Background and History
     1.2 Context and Business Requirements
     1.3 Out of Scope
     1.4 Components of the Specification
           1.4.1 SSP Information Model Document
           1.4.2 SSP Abstract Binding
           1.4.3 SSP Best Practice and Implementation Guide
           1.4.4 SCORM Application Profile
     1.5 Nomenclature
     1.6 References

2. Information Model
     2.1 SSP Conceptual Model
     2.2 SSP Service Description
     2.3 Bucket Class Description
           2.3.1 Structure
           2.3.2 Behaviors
           2.3.3 Data Elements
     2.4 Bucket Allocation Class Description
           2.4.1 Structure
           2.4.2 Behaviors
           2.4.3 Data Elements
     2.5 Bucket State Class Description
           2.5.1 Structure
           2.5.2 Behaviors
           2.5.3 Data Elements
     2.6 Bucket Collection Class Description
           2.6.1 Structure
           2.6.2 Behaviors
           2.6.3 Data Elements
     2.7 Status Info Class Description
           2.7.1 Structure
           2.7.2 Behaviors
           2.7.3 Data Elements
     2.8 Bucket Collection Manager Interface Description
           2.8.1 Structure
           2.8.2 Behaviors
     2.9 Bucket Manager Interface Description
           2.9.1 Structure
           2.9.2 Behaviors

3. Extensibility

Appendix A - Use Cases
     Use Case 1 - Content Communicates to Simulation
     Use Case 2 - Posttest Adjusts Behavior based on Pretest Performance
     Use Case 3 - Embedded Assessment Changes the Format of a Posttest
     Use Case 4 - Sales Simulation in Flash
     Use Case 5 - Simulation Deployment
     Use Case 6 - HLA Simulation: Instrumented Carrier Landing
     Use Case 7 - Car Radio Simulation

About This Document
     List of Contributors

Revision History

Index


1. Specification Overview

This specification describes an extension to e-learning runtime systems (e.g., SCORM) that enables the storage of and shared access to state information between content objects. There is currently no prescribed method for a content object to store (arbitrarily complex) state information in the runtime system that can later be retrieved by itself or by another content object. This capability is crucial to the persistence of the sometimes complex state information that is generated by a variety of interactive content (e.g., simulations) and that is currently stored and retrieved in proprietary formats and through proprietary methods.

1.1 Rationale

Complex interactive content, such as simulation, is becoming increasingly common as developers seek to move beyond first generation static formats to more engaging and effective forms of e-learning. A key building block for interactive content is omitted from current e-learning specifications. If implemented in an interoperable way, this functionality could provide significant benefits to the e-learning community.

The addition of a shared data space that can be accessed by any content object in a defined scope would provide the ability to build and deliver modular interactive content that:

  • can be constructed from re-usable components (where it is currently constructed in more monolithic forms);
  • can store data for further analysis (i.e., for virtual instructors);
  • is portable to other systems;
  • provides more stable/robust state management than if executed client side;
  • behaves more consistently with greater realism;
  • provides more viable simulations.

Support for a shared dataspace allows for a wide range of enhanced learning experiences - as the use cases (included in Appendix A - Use Cases) demonstrate - such as adaptive assessment, adaptive simulations, and other applications as well.

1.1.1 Background and History

The ability to re-create aspects of the real world in an electronic form to support experiential learning is believed by many to be one of the most effective applications of learning technology. Commercial flight simulators and complex military simulations stretch the envelope of realism (and technical complexity) in order to provide hands-on experience where exacting detail can have life and death implications. But complex, immersive simulation is only one flavor of interactive e-learning content - a variety of interactive content types are commonly employed to teach people how to use simple desktop software applications, negotiate sales contracts, or conduct chemical experiments.

A common requirement of most interactive content is the need to store information about the "state" of the learning experience at a given time. State information is usually a collection of data about variables that are important to the content's function. In a flight simulator this would include information about the plane's speed, trajectory, altitude, fuel consumption, and the settings of various controls. In a sales simulation, variables would include things like the attitudes of customers, the facility of the salesperson in responding to customer objections, and a record of sales calls and other activities. In an executive information system, variables would be initiatives and change management tactics used to try to convince the managers to adopt a proposed innovation.

For example, although there are provisions in the SCORM application profile that can be used to load and store state information such as cmi.launch_data and cmi.suspend_data, these data elements are severely limited in size and cannot be accessed by other SCOs. There is no explicit simulation support specified in the existing SCORM runtime, API, or data model. The addition of sequencing in SCORM 2004, however, provides an important building block for constructing modular interactive content composed of re-usable content components or SCOs. In SCORM 2004, the logic for determining how to proceed through these SCOs (based on learner performance) can now be written as sequencing rules and the status of objects can be shared.

What is missing is the ability to store data from one content object that can be retrieved by another so that the content objects can be knit into a complete and integrated learning experience. In a flight simulator for example, each content object may be one in a series of aviation challenges - weather, equipment malfunction, traffic conditions, etc. - that the learner must successfully "navigate". The decisions made by the learner in dealing with each of these challenges affect certain state variables (e.g., the amount of fuel remaining or current airspeed) that in turn will impact the state conditions that are used by later content objects.

Also useful for additional uses such as the ability to review the state of a content object as it was in a previous activity.

1.2 Context and Business Requirements

  1. Content objects can request allocation of an arbitrary number of independent data buckets and access those buckets.
  2. The runtime system needs no knowledge of the syntax of the information stored in a data bucket.
  3. The content object must be able to ascertain the available storage per bucket as allocated by the runtime system.
  4. Data buckets first allocated for one content object can be accessed by other content objects within a defined scope.
  5. Content objects may provide data bucket storage requirements in a manner that does not require launch of the content object to discover the storage requirements.
  6. The minimum and preferred data bucket requirements for a content object may be explicitly specified as discoverable properties of the content object.
  7. A content object may declare minimum and preferred data bucket requirements at runtime.
  8. The duration of persistence of the bucket's data will be specified so as to balance the content developer's need for flexibility and the data management burden for the runtime system.
  9. This specification should clearly identify types of data that should not be persisted using this mechanism as there are other specifications that provide for interoperability and persistence of that data (e.g., QTI, SS, etc.).
  10. Content objects may access a given data bucket independently of the existence of any other data bucket.
  11. The runtime system must be able to allocate data bucket storage prior to the content object accessing the buckets.
  12. Content objects are responsible for knowing the IDs of the buckets they need to access.

1.3 Out of Scope

The following are out of scope for this specification:

  1. The specification does not describe any data model for the contents of buckets (e.g., simulation state information).
  2. Communication between a content object and an external process (e.g., a simulation running outside of the SCO).
  3. The data contained in buckets shared between vendors (i.e., any implementer may establish a proprietary usage of a data model dependency between its learning objects).
  4. Dynamic expansion and contraction of buckets (however, this would be very useful for later functionality).
  5. Synchronization of read/write access, blocking and/or locking of buckets, etc. Application profiles of this specification may need to add this type of functionality.
  6. Offline access to buckets.
  7. Discoverability of a bucket's data formats.
  8. How an application profile specifies availability of buckets for multiple content objects.
  9. How an application profile specifies availability of buckets for multiple learners.
  10. Defining the outer boundaries for the uniqueness of bucket IDs.
  11. External access (by other processes) to buckets.

1.4 Components of the Specification

This specification includes the documents listed below.

1.4.1 SSP Information Model Document

Describes the core aspects of the specification and contains parts that are normative for any binding claiming to use this Information Model. It contains details of: semantics, structure, data types, value spaces, multiplicity, and obligation (i.e., whether mandatory or optional).

1.4.2 SSP Abstract Binding

Describes a binding of the SSP Information Model to XML version 1.0 and is normative for any XML instance that claims to use this binding, whether by reference to the specification or by declaration of the namespace reserved by the specification. In cases of error or omission, the Information Model takes precedence. The SSP Abstract Binding will be released with a control document using W3C Schema Language that should be used in implementations.

1.4.3 SSP Best Practice and Implementation Guide

The Best Practice and Implementation Guide includes (but is note limited to) the following:

  • References such as Proposal for a Generic Storage Service Data Model.
  • Clearly identifying types of data that should not be persisted using this mechanism as there are other specifications that provide for interoperability and persistence of that data (e.g., QTI, SS, etc.).

1.4.4 SCORM Application Profile

Describes a proposed binding of the SSP Information model to SCORM.

1.5 Nomenclature

 
ADL Advanced Distributed Learning
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
ISO International Organization for Standardization
LOM Learning Object Metadata (usually used in "IEEE LOM")
LTSC Learning Technology Standards Committee
RFC Request for Comment (usually used in "IETF RFC xxxx")
SCO Sharable Content Object
SCORM Sharable Content Object Reference Model
SSP IMS Shareable State Persistence Specification
VDEX IMS Vocabulary Definition Exchange Specification
W3C World Wide Web Consortium
XML Extensible Mark-up Language

1.6 References

 
[SSP, 04b] IMS Shareable State Persistence XML Binding v1.0, A.Jackl, B.Towle, IMS Global Learning Consortium, Inc., June 2004.
[SSP, 04c] IMS Shareable State Persistence Best Practice and Implementation Guide v1.0, A.Jackl, IMS Global Learning Consortium, Inc., June 2004.
[SSP, 04d] IMS Shareable State Persistence SCORM Application Profile v1.0, A.Jackl, A.Panar, B.Towle, IMS Global Learning Consortium, Inc., June 2004.
[IEEE LOM] IEEE 1484-12:2002, Standard for Learning Object Metadata, (http://ltsc.ieee.org)
[IMSBUND] Using IMS Content Packaging to Package Instances of LIP and Other IMS Specifications v1.0, B.Olivier, M.McKell, IMS Global Learning Consortium, Inc., August 2001.
[IMSPLID] IMS Persistent, Location-Independent, Resource Identifier Implementation Handbook v1.0, M.McKell, IMS Global Learning Consortium, Inc., April 2001.
[RFC 1766] Tags for the Identification of Languages, (http://www.ietf.org)
[URI] IETF RFC 2396:1998, Universal Resource Identifiers (URI): Generic Syntax (http://www.ietf.org)

2. Information Model

2.1 SSP Conceptual Model

The SSP conceptual model depicts (in Figure 2.1) how the SSP specification intends to address its two fundamental technical requirements: enabling a content object to declare its storage needs and providing an interface for a content object to access that storage. A content object may require space to store its state data or it may require access to a known (through ID) set of state data created by another content object. A content object will declare these requirements by defining a set of Bucket Allocations either prior to or after launch. The runtime system, prior to launching a content object, will attempt to ensure storage space is made available to the content object based on that object's defined Bucket Allocations. After launch, a content object will access its storage space through well-defined interfaces.

A representation of the SSP conceptual model

 

Figure 2.1 A representation of the SSP conceptual model.

2.2 SSP Service Description

The diagram in Figure 2.2 is an illustration of the SSP service description.

A representation of the SSP service description

 

Figure 2.2 A representation of the SSP service description.

2.3 Bucket Class Description

2.3.1 Structure

The Bucket class describes a single data bucket (described by an ID).

Note: A bucket must be allocated before it can be used. The SSP service is responsible for ensuring the correct data (Bucket) is accessed, given the context of that access.

2.3.2 Behaviors

None.

2.3.3 Data Elements

 
No. Element Description Type Mult Notes
1. bucketID The identifier of the requested bucket. GUID 1
 
2. bucketType Reference to a type definition for the bucket's data. GUID 0..1 This element is provided for systems that may wish to use additional type information. The definition of bucket types and their use is out of scope for the SSP specification.
If not specified, the runtime system will assign a default bucketType.
3. data The data stored in this bucket. Sequence of Octets 1
 
4. minimum Describes the minimum amount of space requested when this bucket was allocated. Non-negative Integer 1 In octets.
5. persistence Describes how long the runtime system should persist the data in the bucket. Token: one of:
- session
- course
- learner
0..1 If not provided, the default is learner.
6. reducible Indicates if the amount of space requested was allowed to be reduced when this bucket was allocated. Boolean 1
 
7. requested Describes the amount of space requested when this bucket was allocated. Non-negative Integer 1 In octets.
8. totalSpace The total amount of space available for this bucket.
This number is determined once, upon bucket allocation, based on the bucket's allocation requirements.
Note: This element does not necessarily represent the 'allocated' space for the bucket. Instead, it is the amount of space the Runtime System has committed to the bucket, based on the bucket's allocation requirements.
Non-negative Integer 1 In octets.
9. used Describes the amount of space currently used in the bucket. Non-Negative Integer 1 In octets.

2.4 Bucket Allocation Class Description

2.4.1 Structure

The Bucket Allocation class describes the allocation requirements for a single bucket (described by an ID).

2.4.2 Behaviors

None.

2.4.3 Data Elements

 
No. Element Description Type Mult Notes
1. bucketID The identifier of the requested bucket. GUID 1
 
2. bucketType Reference to a type definition for the bucket's data. GUID 0..1 This element is provided for systems that may wish to use additional type information. The definition of bucket types and their use is out of scope for the SSP specification.
If not specified, the runtime system will assign a default bucketType.
3. minimum Describes the minimum amount of space requested when this bucket is allocated. Non-negative Integer 0..1 In octets.
If provided, minimum must not exceed requested.
4. persistence Describes how long the system should persist the data in the bucket once the bucket is allocated. Token: one of:
- session
- course
- learner
0..1 If not provided, the default is learner.
5. reducible Indicates if the amount of space requested is allowed to be reduced to the minimum amount when this bucket is allocated. Boolean 0..1 If not provided, the default is false.
If this element is false, the value of minimum is not considered during allocation.
6. requested Describes the amount of space requested when this bucket is allocated. Non-negative Integer 1 In octets.

2.5 Bucket State Class Description

2.5.1 Structure

The Bucket State class describes the current state of a particular bucket. It is passed back to the content object in response to queries.

2.5.2 Behaviors

None.

2.5.3 Data Elements

 
No. Element Description Type Mult Notes
1. bucketType Reference to a type definition for the bucket's data. GUID 1 This element is provided for systems that may wish to use additional type information. The definition of bucket types and their use is out of scope for the SSP specification.
If not specified, the runtime system will assign a default bucketType.
2. totalSpace The total amount of space available for this bucket.
This number is determined once, upon bucket allocation, based on the bucket's allocation requirements.
Note: This element does not necessarily represent the 'allocated' space for the bucket. Instead, it is the amount of space the Runtime System has committed to the bucket, based on the bucket's allocation requirements.
Non-negative Integer 1 In Octets
3. used Describes the amount of space currently used in the bucket. Non-negative Integer 1 In Octets

2.6 Bucket Collection Class Description

2.6.1 Structure

The Bucket Collection class describes and maintains the current set (collection) of buckets available to a content object.

The runtime system is responsible for managing the relationship between bucket collections and learners.

2.6.2 Behaviors

None.

2.6.3 Data Elements

 
No. Element Description Type Mult Notes
1. managedBuckets The set of data buckets being managed by the system for the identified content object.
 
0..n
 
1.1. bucketID The ID of one bucket being managed by the system for the identified content object. GUID 1
 
1.2. success The allocation success of the bucket Token: one of:
- failure
- minimum
- requested
- noneRequested
1 If allocation for a content object fails, that result is maintained here along with the identified bucket, but access to the identified bucket is not guaranteed.

2.7 Status Info Class Description

2.7.1 Structure

The Status Info class describes the error state information of an API function invocation.

2.7.2 Behaviors

None.

2.7.3 Data Elements

The definition of this is parallel to the StatusInfo object in the Common Data Definitions.

 
Element Description Type Mult Notes
errorCode Identifies the error state of the function invocation. Integer 1
 
errorDesc Describes the error state of the function invocation. String 1
 

2.8 Bucket Collection Manager Interface Description

2.8.1 Structure

The Bucket Collection Manager interface provides a content object access to the set of buckets explicitly requested by the content object.

Note: Bucket Collections (and, by extension, buckets) are not shared between learners. Rather, a new BucketCollection is instantiated for each additional learner interacting with the same content object.

2.8.2 Behaviors

  • allocate() - to allocate a bucket
  • getBucketIDs() - to request the set of bucket identifiers explicitly requested for this content object
  • getAllocationStatus() - to request from the status of the allocation of a specific bucket associated with the content object

2.8.2.1 Allocate

 
Name: allocate()
Return value: The StatusInfo object.

Note: Invoking the allocate() operation never fails, however the status of the allocated bucket may be failure. Content objects should not assume the requested bucket exists after invoking the allocate() operation, instead they should call getAllocationSuccess() to determine the results of the allocate() operation.

Supplied (in) parameters:
  • Bucket Allocation: the definition of the allocation requirements for the bucket.
Returned (out) parameters: None
Behavior: The service shall reserve storage space for the content object according to the parameters set forth in the request.

Note: "Reserving" space does not mean that the space must be physically allocated; the only requirement is that the space be available when the content object attempts to write to it. This allows implementations to use various just-in-time allocation methods, should they desire. If the content object puts data in the bucket, the service shall persist that data as described by the persist parameter.


The service has four options for how much space to assign, corresponding to the values of requested, minimum, and reducible in the BucketAllocation object.


1. If reducible = false and the system has sufficient storage to provide the requested amount of space, the requested amount of storage is assigned.
2. If reducible = true and the system does have sufficient storage to provide the requested amount of space, the requested amount of storage is assigned.
3. If reducible = true and the system does not have sufficient storage to provide the requested amount of space, but does have sufficient storage available for the reduced amount, the reduced amount of storage is assigned.
4. If none of the above cases are true, the system does not provide any space for the bucket.


If the value of BucketAllocation:bucketID matches the identifier of a bucket that already exists and the specified values for reducible, minimum, requested, persistence, and bucketType all match those associated with the existing bucket (supplied in the original allocation request), the service shall not allocate a new bucket. Rather, the content object shall be given access to the bucket that already exists and the Success Status of the current allocation request shall match the Success Status of the original request.


If the value of BucketAllocation:bucketID matches the identifier of a bucket that already exists and supplies a value of reducible, minimum, requested, persistence, or bucketType that is different from the same attribute associated with the existing bucket (supplied in the original allocation request), it is an error. In this case:

  • The content object requesting inconsistent allocation of the existing bucket is not given access to the existing bucket.
  • The service shall not change the allocation of the existing bucket.
  • Any attempted access to the existing bucket by the content object shall throw a "Bucket Improperly Declared" error.
Additional allocation requests for the bucket by other content objects shall be treated independently; if the declaration is proper, it is not an error, even if other, improper declarations had previously occurred.

2.8.2.2 Get Allocation Success

 
Name: getAllocationSuccess()
Return value:

The StatusInfo object.

Supplied (in) parameters: GUID: the identifier of the desired bucket.
Returned (out) parameters: successStatus: The status of the allocation request for the identified bucket. The permitted status codes are:
  • "failure" - The allocation for the specified bucket failed because the runtime system could not allocate the requested space, or the request conflicted with the existing allocation of the specified bucket. No space has been allocated.
  • "minimum" - The allocation for the specified bucket has been made at a minimum level. Buckets with reducible = false have been granted at the requested level, and buckets with reducible = true have been granted at the minimum level.
  • "requested" - The allocation request for the specified bucket has been granted as requested.
  • "noneRequested" - No allocation request has been made for the specified bucket.
Behavior: The service shall return the successStatus token corresponding to the allocation of the content object's request.

2.8.2.3 Get Bucket Identifiers

 
Name: getBucketIDs()
Return value:

The StatusInfo object.

Supplied (in) parameters: None
Returned (out) parameters: A list of bucket identifiers accessible to the content object.
Behavior: The service shall return the list of bucketIDs for the buckets that have been requested for allocation for the content object - the collection of ManagedBuckets. If the ManagedBucket collection is empty, the service shall return an empty list.
Notes: For the learner, buckets other than those requested for allocation by the content object may be available to the content object; the bucketIDs for these buckets shall not be included in the list.

2.9 Bucket Manager Interface Description

2.9.1 Structure

The Bucket Manager interface provides access to a single bucket.

2.9.2 Behaviors

  • getData() - to request from the server the data currently in the bucket.
  • getDataOffset() - to request from the server the data currently in the bucket with an offset.
  • setData() - to put a block of data in the bucket, replacing whatever data is currently in the bucket.
  • setDataOffset() - to put a block of data in the bucket, replacing whatever data is currently in the bucket with an offset.
  • appendData() - to put a block of data in the bucket, starting at the end of the current data.
  • getState() - to get the current state of the bucket.

2.9.2.1 Get Data

 
Name: getData()
Return value:

The StatusInfo object. The permitted error codes are:

  • 'Bucket Does Not Exist' - The service cannot resolve the specified bucket within the context on the operation.
  • 'Bucket Improperly Declared' - The content object's requirements for the specified bucket conflict with an existing allocation for the same bucket.
Supplied (in) parameters:

GUID: the identifier of the desired bucket.

Returned (out) parameters: Sequence of Octets: (all of) the data currently in the bucket.
Behavior: The service shall return all of the data currently in the bucket. If there is no data in the bucket, the service shall return a zero-length sequence of octets and the appropriate something-or-other code.
Notes: With this function, as with all bucket access functions, a content object is allowed to access a bucket that it did not explicitly declare. If the bucket does exist, the service should allow the operation to take place. If the bucket does not exist, the service shall throw a Bucket Does Not Exist error.

2.9.2.2 Get Data at Offset

 
Name: getDataOffset()
Return value: The StatusInfo object.
The permitted error codes are:
  • 'Bucket Does Not Exist' - The service cannot resolve the specified bucket within the context on the operation.
  • 'Bucket Improperly Declared' - The content object's requirements for the specified bucket conflict with an existing allocation for the same bucket.
  • 'Offset Exceeds Bucket Size' - The start of the requested data (the offset) exceeds the total size of the specified bucket.
  • 'Requested Data Exceeded Available Data' - The bucket does not contain enough data from the start of the requested data (offset).
Supplied (in) parameters:
  • GUID: the identifier of the desired bucket.
  • Non negative Integer: indicates where in the bucket to start reading - the offset.
    Note: This is an optional value. If not specified, the offset is the beginning of the data bucket (offset == 0).
  • Non-negative Integer: indicates how much data (size in octets) to return from the starting offset.
Returned (out) parameters: Sequence of Octets: (all of) the data in the range defined by the offset and the requested size.
Behavior: With this function, as with all bucket access functions, a content object is allowed to access a bucket that it did not explicitly declare. If the bucket does exist, the service should allow the operation to take place. If the bucket does not exist, the service shall throw a Bucket Does Not Exist error. If there is no data in the bucket and a non-zero offset is declared, the service shall return a zero-length sequence of octets and the Requested Data Exceeded Available Data error is thrown.

2.9.2.3 Set Data

 
Name: setData()
Return value: The StatusInfo object.
The permitted error codes are:
  • 'Bucket Does Not Exist' - The service cannot resolve the specified bucket within the context on the operation.
  • 'Bucket Improperly Declared' - The content object's requirements for the specified bucket conflict with an existing allocation for the same bucket.
  • 'Bucket Size Exceeded' - The provided sequence of octets is larger than the size of the bucket.
Supplied (in) parameters:
  • GUID: the identifier of the desired bucket.
  • Sequence of Octets: the data to be put into the bucket.
Returned (out) parameters: None.
Behavior: If the provided data will fit in the bucket, the service shall replace the current contents of the bucket with the supplied sequence of octets.
If an empty sequence is provided, the existing data is cleared.
Notes: With this function, as with all bucket access functions, a content object is allowed to access a bucket that it did not explicitly declare. If the bucket does exist, the service should allow the operation to take place. If the bucket does not exist, the service shall throw a Bucket Does Not Exist error.

2.9.2.4 Set Data at Offset

 
Name: setDataOffset()
Return value: The StatusInfo object.
The permitted error codes are:
  • 'Bucket Does Not Exist' - The service cannot resolve the specified bucket within the context on the operation.
  • 'Bucket Improperly Declared' - The content object's requirements for the specified bucket conflict with an existing allocation for the same bucket.
  • 'Offset Exceeds Bucket Size' - The start of the data (the offset) exceeds the total size of the specified bucket.
  • 'Bucket Size Exceeded' - The provided sequence of octets is larger than the size of the bucket.
  • 'Bucket Not Packed" - The start of the data (the offset) is greater than the amount of data currently in the bucket.
Supplied (in) parameters:
  • GUID: the identifier of the desired bucket.
  • Non negative Integer: indicates where in the bucket to start reading - the offset.
  • Sequence of Octets: the data to be put into the bucket.
Returned (out) parameters: None.
Behavior: The service shall replace the current contents of the bucket at the given offset with the supplied sequence of octets.
Notes: With this function, as with all bucket access functions, a content object is allowed to access a bucket that it did not explicitly declare. If the bucket does exist, the service should allow the operation to take place. If the bucket does not exist, the service shall throw a Bucket Does Not Exist error.

2.9.2.5 Append Data

 
Name: appendData()
Return value: The StatusInfo object.
The permitted error codes are:
  • 'Bucket Does Not Exist' - The service cannot resolve the specified bucket within the context on the operation.
  • 'Bucket Improperly Declared' - The content object's requirements for the specified bucket conflict with an existing allocation for the same bucket.
  • 'Bucket Size Exceeded' - The provided sequence of octets is larger than the size of the bucket.
Supplied (in) parameters:
  • GUID: the ID of the desired bucket.
  • Sequence of Octets: the data to be appended to the bucket's existing data.
Returned (out) parameters: None
Behavior: The service shall add the sequence of octets to the end of the bucket. This is a simple octet-append; the service shall not do any integrity checking.
Notes: With this function, as with all bucket access functions, a content object is allowed to access a bucket that it did not explicitly declare. If the bucket does exist, the service should allow the operation to take place. If the bucket does not exist, the service shall throw a Bucket Does Not Exist error.

2.9.2.6 Get State

 
Name: getState()
Return value: The StatusInfo object.
The permitted error codes are:
  • 'Bucket Does Not Exist' - The service cannot resolve the specified bucket within the context on the operation.
  • 'Bucket Improperly Declared' - The content object's requirements for the specified bucket conflict with an existing allocation for the same bucket.
Supplied (in) parameters:
  • GUID: the identifier of the desired bucket.
Returned (out) parameters:
  • BucketState: the current state of the specified bucket.
  • "totalSpace" - the total amount of space available for this bucket (non-negative integer)
  • "used" - the amount of space currently used in the bucket (non-negative integer)
  • "bucketType" - the type definition for the bucket's data (GUID)
Behavior: The service shall return a BucketState object whose elements have been set to indicate the current state of the specified bucket.
Note: If the bucket does not exist or is improperly declared occurs, nothing is returned.
Notes: With this function, as with all bucket access functions, a content object is allowed to access a bucket that it did not explicitly declare. If the bucket does exist, the service should allow the operation to take place. If the bucket does not exist, the service shall throw a Bucket Does Not Exist error.

3. Extensibility

Extensions shall be permitted. Extensions should not re-define the existing abstract API; rather, they should add to it.

Appendix A - Use Cases

Note: The use cases included in this document were gathered during the Charter development process, and are informal use cases that define the business needs and requirements for this specification.

Use Case 1 - Content Communicates to Simulation

Players

  • Learner
  • Content Items
  • LMS
  • Simulation

Assumptions

The student has an account on the LMS, and is logged on.

Description

While interacting with a course, the learner experiences various content items that have assessment included in them.

These content items store (in the shared data space on the LMS) information about the student's performance on the included assessment.

Later in the course, the student takes a simulation. The simulation reads (from the shared data space) the record of how the student performed on the assessment in the content, and adjusts its functioning accordingly, emphasizing objectives that the student had difficulty within the content.

Other factors

  • Note that the student's interaction with the content may or may not occur in the same login session as the student's interaction with the simulation. In either case, however, the information is required to be available to the simulation.
  • Note that the strategy employed by the simulation and the method by which it emphasizes objectives that were difficult to the learner are both out of scope.

Use Case 2 - Posttest Adjusts Behavior based on Pretest Performance

Players

  • Learner
  • Pretest
  • Posttest
  • LMS

Assumptions

The student has an account on the LMS, and is logged on.

Description

During his/her interactions with a course, the learner takes a pretest. The pretest writes out a record of which questions were asked, and of the learner's performance on those questions.

Later in the course, the learner takes a posttest. The posttest reads the data from the shared data space that had been put there by the posttest, and gives the learner a different set of questions than the one that had been given in the pretest.

Optionally, the posttest may repeat questions that were missed in the pretest. Either way, the record of questions taken is read from the shared data space.

Other factors

  • Note that the student's interaction with the pretest may or may not occur in the same login session as the student's interaction with the post-assessment. In either case, however, the information is required to be available to the post-assessment.
  • Note that the strategy employed by the pretest and the method by which it repeats or skips questions are both out of scope.

Use Case 3 - Embedded Assessment Changes the Format of a Posttest

Players

  • Student
  • Content SCOs
  • Posttest
  • LMS

Assumptions

The student has a valid account with the LMS, and is logged on.

Description

During interaction with a course, the learner experiences various content items that have assessment included in them.

These content items store (in the shared data space on the LMS) information about the student's performance on the included assessment.

Later in the course, the student takes a post-assessment. The post-assessment reads (from the shared data space) the information about the student's performance on the assessment in the content, and uses that to tailor the post-assessment appropriately.

Exceptions

If the LMS cannot store the data requested by the content items, it should notify them appropriately.

Other Factors

Note that the student's interaction with the content may or may not occur in the same login session as the student's interaction with the post-assessment. In either case, however, the information is required to be available to the post-assessment.

Note that the method used by the post-assessment to tailor the assessment appropriately is out of scope.

Use Case 4 - Sales Simulation in Flash

Players

  • Simulation
  • Simulation SCOs
  • Learner
  • Delivery System

Assumptions

Learner has a valid enrollment in the simulation course.

Description

A sales training simulation, authored in Flash, is a series of interactive scenarios or vignettes. Each of the scenarios is an independent content object. In each content object the learner interacts with "customers" as she moves through the process of selling a complex product.

After each interaction the content object saves data about the learner's performance across a variety of vectors - how well did she prepare, handle objections, understand the customer's business, position the competition, etc. The performance data is saved in the learning delivery system. In later content objects the learner's performance across these vectors is retrieved from the delivery system by the content object and used to pre-configure the simulation to behave in a manner that is appropriate to the learner's prior performance.

Other factors

  • The simulation may be arbitrarily complex
  • Simulation SCOs may store and retrieve strings entered by the learner
  • The simulation may be resumed in another learning session

Use Case 5 - Simulation Deployment

Players

  • Learning Delivery System
  • Course
  • Course Deployer - person who deploys the course to the delivery system

Description

A course is created that utilizes the SSP service to store simulation state variables. As part of instantiating these state variables the course developer uses meta-data to define the upper and lower limits of data storage that will be required at runtime for each SSP variable.

The delivery system supports business rules which define the maximum storage allowable for any course. The rules may be specified globally or for a given user or users of the delivery system. If the data storage requirements in the course package are within allowable limits the package is successfully deployed to the delivery system. If the data storage requirements exceed the system's limits the course deploy may be rejected or the system may provide functionality that allows course requirements to be changed.

Other Factors

The specifics of exception handling are implementation specific and out of scope.

Use Case 6 - HLA Simulation: Instrumented Carrier Landing

Players

  • Learner
  • Content SCOs
  • Virtual Instructor SCOs
  • HLA Simulation
  • LMS

Assumptions

Student logged into LMS, enrolled in course, LMS has determined correct mode to present course to student (e.g., self-paced, structured, or tailored).

Introductory content SCO presented introductory material to student.

Description

High-Level Architecture (HLA) is a messaging and interoperability protocol used in flight simulators developed for the DoD. In DoD-type simulations, tanks, aircraft, etc., join an HLA federate where they can all see each other and have group practice and simulation. For example, two aircraft can fight with or against each other. Threat boxes, e.g., anti-aircraft guns, can be placed within the simulated environment. For non-DOD simulations, other vehicles, like ships, planes, trains, etc. could be used.

In most HLA federations, the HLA packets cover data that describes what an object is, what it looks like, and where it is. In a learning environment with HLA, the SCO is like a Virtual Instructor (VI) which uses HLA to monitor what the student is doing. The Virtual Instructor (VI):

  • Establishes the original context
  • Invokes and Initializes the simulation
  • Provides feedback and assistance to the student
  • Sends commands to the SCOs to adjust the simulation's behavior appropriately


The Student:


  • Performs the simulation
  • Receives feedback and assistance from the VI

For this demonstration, the training is an instrumented carrier landing. The SCO passes simulation initialization data via HLA, placing the student at a given altitude, speed, etc., at a given distance from the carrier, and with specific environmental conditions. The student performs the landing. The simulation then passes student and aircraft information via HLA, allowing the SCO to evaluate such factors as the student's control of airspeed, approach glide angle, timing on flaps and landing gear, etc.

This evaluation forms the basis for feedback and updates to student competencies. Based on performance, the LO may be passed and the student continues with the next LO, or an exercise addressing the same LO is selected.

Transactions

The communications between the selected SCO and the HLA simulation are described below and summarized in a graphic.

 

Once launched by the LMS, the selected SCO presents to the student the objective(s) and the initial conditions for the simulation exercise.

  • The SCO sends an HLA packet to initialize the simulation, i.e., place the aircraft in the designated position and environment for the exercise.
  • The SCO subscribes to simulation's HLA packets.
  • The student performs the task in the simulation.
  • During the task, the simulation sends information about the aircraft status and data about student performance to the SCO, using HLA.
  • The SCO contains the logic and parameters to evaluate student actions.
  • The SCO displays performance feedback to the student and sends the performance data to the LMS, including a measure of mastery/competency on the applicable LOs.
  • Upon completion of the task, the SCO sends a score summary, completion status, and mastery status to LMS.
  • Finally, the SCO sends override commands to the simulation, using HLA and terminating the simulation exercise.
SCO sends LMSFinish() to LMS.

Exceptions

Each SCO either checks to see if the simulation is running and establishes link if it is and launches it if it is not running, or each SCO always launches the simulation and the simulation checks to see if it is already running.

Each SCO verifies that simulation states are appropriately set, setting the states as required.

Other Factors

  • Note that the student's interaction with the content may or may not occur in the same login session as the student's interaction with the post-assessment. In either case, however, the information is required to be available to the post-assessment.
  • Note that items 2, 3, 5, and 9 in the "Transactions" section concerning specific communications between the SCOs and the simulation are out of scope of the SSP Project Team.

Use Case 7 - Car Radio Simulation

Players

  • Student
  • Content SCOs with "Virtual Instructor"
  • Car Radio Simulation
  • LMS

Assumptions

  • Student logged into LMS, enrolled in course, LMS has determined correct mode to present course to student (e.g., self-paced, structured, or tailored).
  • Introductory content SCO presented introductory material to student.

Description

General Description - Student is taught how to operate a car radio by interacting with ADL/SCORM-Compliant SCOs and a simulation of the subject car radio. The SCOs have been written to teach the following learning objectives (LOs): The student will be able to:

1. Perform basic day to day operations of the radio

1.1. Power On/Off

1.2. Control volume

1.3. Select preset stations

1.4. Tune station

1.4.1. Manual

1.4.2. Scan

1.4.3. Seek

1.5. Change bands (AM/FM)

2. Perform occasional operations

2.1. Control balance and fader (left/right & front/back)

2.2. Control equalizer (treble & bass adjustments)

3. Perform advanced occasional procedures of the radio

3.1. Set radio station presets

3.2. Set time display

Each two-digit LO is taught by its own SCO (i.e., 9 total SCOs, LO 1 has 5 SCOs and the "Tune station" SCO teaches all three methods).

Detailed Description - Content SCO for teaching "Power On/Off" launched by LMS. Simulation is also started by either SCO or LMS. Simulation is initialized to power off state, correct time is showing on display of simulation. SCO instructs student to turn radio on by pressing the power/volume switch. At this time, the SCO's "next" button is disabled. If the student presses the wrong button or several seconds have elapsed without student pressing the correct button, the SCO responds with text such as, "The power/volume switch is the large, round switch on the left." The button is highlighted in the simulation with a soft blue glow around it. When the student clicks on the power/volume switch, the simulation changes power state to on; the display shows a radio frequency rather than the time; simulated radio audio is played; and the blue glow is turned off. The SCO congratulates the student and the student is told that powering off the radio is done the same way. If the student still does not press the correct switch, the blue glow changes to yellow and the student is reminded where the switch is. The student may click on the switch in the simulation or may press "next" in the SCO. The SCO sends "complete" (LMSSetValue("cmi.core.lesson_status", "complete") & LMSComplete("") ) to the LMS and the LMS launches the next SCO while the simulation remains displayed.

The "Control Volume" SCO is launched and the student is lead in a very similar way through setting the volume of the radio except that the student must click & drag the mouse rather than just click. The student must click & drag to the left or down to lower the volume and to the right or up to raise the volume. The simulation responds by lowering and raising the volume of the simulated audio. The student must perform both raising and lowering the volume. The student is asked to turn the volume all the way down and all the way up. The minimum and maximum positions are highlighted at the appropriate time if the student does not perform the requested action. Once the student performs everything correctly, the "next" button is activated and the student presses it. The SCO sends "complete" to the LMS and the LMS launches the next SCO while the simulation remains displayed.

Other SCOs are presented in the same way. In the "Tune Station" SCO, the student is asked to tune the radio to specific radio frequencies such as "90.7." The student is guided to the appropriate switch as in the "Power On/Off" and "Control Volume" SCOs. If the student uses the correct switch but does not set the correct frequency, the SCO shows the student what direction to rotate the switch (drag the mouse) by commanding the simulation to display specific arrows. In the "Set radio station presets" SCO, the student may be remediated back to the "Tune Station" SCO if the student fails to set the frequency appropriately. Upon passing the "Tune Station" SCO, the student is allowed to try the "Set radio station presets" SCO.

Transactions

The simulated radio needs to have continuity between instances of the simulation. For example, when the student sets the volume in topic 1.2 and manually sets the station in topic 1.4.1, then those settings will remain in effect when simulated radio is presented for topic 1.4.2. Additionally, when the user sets favorite stations, those presets are available when the course is resumed at a latter date. At a minimum, the simulation should retain states such as:

  1. power on,
  2. display mode,
  3. time or deviation from local time (default is current local time),
  4. current station,
  5. volume, fader and equalizer settings.
      • When multiple SCOs are presented in a particular session, the continuity is achieved by keeping the simulation running between SCOs while each SCO must be careful to only set states if necessary.

        When the user returns to the course at a later date, the continuity is achieved by saving the states in the LMS.
      • Note that how the simulation is launched or invoked, and how a simulation keeps running between invocations by content objects, is out of scope for the proposed SSP Working Group charter.
      • All communication to the LMS is done by the SCO. For example, the SCO evaluates (assesses) the student and sends the assessment data to the LMS. Additionally, the SCOs are responsible for obtaining the states from the simulation to store in the LMS, retrieving the states from the LMS at a later date, and (re)initializing the simulation to those states.

Note: The mechanism used for the "two-way" communication between the content objects and the simulation in the third bullet under "Transactions" is out of scope of the SSP Charter.

The car radio simulation and the car radio training content have two-way communication. As the user interface, the simulation must communicate to the training content all student interactions with the car radio. Acting as a "virtual instructor," the SCO must be notified of every action the student performs in the simulation. The SCO must be able to initialize the simulation, change states, highlight controls, and restrict or intercept student actions in the simulation.

Exceptions

  • Each SCO either checks to see if the simulation is running and establishes link if it is and launches it if it is not running or each SCO always launches the simulation and the simulation checks to see if it is already running.
  • Each SCO verifies that simulation states are appropriately set, setting the states as required.

Other Factors

Note that the student's interaction with the content may or may not occur in the same login session as the student's interaction with the post-assessment. In either case, however, the information is required to be available to the post-assessment.

About This Document

 
Title IMS Shareable State Persistence Information Model
Editor Alex Jackl (IMS), Angelo Panar (ADL), Brendon Towle (Thomson NETg)
Team Co-Lead Robert Todd (DigitalThink)
Version 1.0
Version Date 18 June 2004
Status Final Specification
Summary This document describes the Shareable State Persistence Information Model
Revision Information June 2004
Purpose This document has been approved by the IMS Technical Board and is made available for adoption.
Document Location http://www.imsglobal.org/ssp/sspv1p0/imsssp_infov1p0.html

 
To register any comments or questions about this specification please visit: http://www.imsglobal.org/developers/ims/imsforum/categories.cfm?catid=21

List of Contributors

The following individuals contributed to the development of this document:

 
Name Organization Name Organization
Brandt Dargue Boeing Angelo Panar ADL
Jeff Falls ADL James Simon Sun Microsystem
Fabrizio Giorgini GIUNTI Martin Spence Act E-Learning
Alex Jackl IMS Robert Todd DigitalThink
Steve Jeyes CETIS Brendon Towle Thomson NETg
Owen McGrath UCBerkeley Edith Wells Boeing
Claude Ostyn Click2learn, Inc.
 

 

Revision History

 
Version No. Release Date Comments
Base Document 1.0 16 November 2003 Initial version of the SSP specification.
Public Draft 1.0 25 March 2004 First public version of the specification.
a) Updated Figure 2.1 and Figure 2.2.
b) Removed definition elements <contentScope> and <learnerScope>.
c) Renamed getSuccessStatus() behavior to getAllocationStatus().
d) Made minor editorial changes and corrections.
Final Specification 1.0 18 June 2004 Formal Final Release of the specification.

Index

A
Assessment 1, 2
     Post 1, 2, 3
 

B
Binding 1
Bucket
     element 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
Bucket Allocation 1, 2, 3, 4, 5
Bucket Collection 1
Bucket Collection Manager 1
Bucket State 1
 

D
Data bucket 1, 2, 3, 4
Definition 1, 2, 3, 4, 5, 6

G
GUID 1, 2, 3, 4, 5, 6, 7, 8

I
IEEE 1, 2
IMS Specifications
     Content Packaging 1
     Learner Information Package 1
     Question and Test Interoperability 1, 2
 

L
LMS 1, 2, 3, 4, 5, 6
LOM 1, 2
LTSC 1

M
meta-data 1

P
Profile 1, 2

R
RFC 1
Runtime 1, 2, 3, 4, 5, 6, 7, 8

S
SCO 1, 2, 3, 4, 5, 6, 7, 8, 9
SCORM 1, 2
See SCO 1
Structure 1

V
Vocabulary 1

W
W3C 1

X
XML 1

 

 

 

IMS Global Learning Consortium, Inc. ("IMS") is publishing the information contained in this IMS Shareable State Persistence Information Model ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.

IMS 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 would appreciate receiving your comments and suggestions.

Please contact IMS through our website at http://www.imsglobal.org

Please refer to Document Name:
IMS Shareable State Persistence Information Model Revision: 18 June 2004