IMS Shareable State Persistence v1.0- Summary
|Background and history
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, these data stores 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.
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.
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
|Components of the Specification
This specification includes the documents listed below:
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).
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.
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.).
4. SCORM Application Profile
Describes a proposed binding of the SSP Information model to SCORM.
|Shareable State Persistence Conceptual Model
The SSP conceptual model depicts (in figure below) 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 launch 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.
Representation of the SSP Conceptual model