 |
1EdTech Shareable State Persistence Information Model Version 1.0 Final Specification |
Copyright © 2004 1EdTech Consortium, Inc. All Rights Reserved.
The 1EdTech Logo is a trademark of 1EdTech Consortium, Inc.
Document Name: 1EdTech 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.
1EdTech 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 1EdTech's procedures with respect to rights in 1EdTech specifications can be found at the 1EdTech Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.
Copyright © 2004 1EdTech Consortium. All Rights Reserved.
If you wish to copy or distribute this document, you must complete a valid Registered User license registration with 1EdTech and receive an email from 1EdTech granting the license to distribute the specification. To register, follow the instructions on the 1EdTech website: http://www.imsglobal.org/specificationdownload.cfm.
This document may be copied and furnished to others by Registered Users who have registered on the 1EdTech 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 1EdTech, except as needed for the purpose of developing 1EdTech specifications, under the auspices of a chartered 1EdTech project group.
Use of this specification to develop products or services is governed by the license with 1EdTech found on the 1EdTech website: http://www.imsglobal.org/license.html.
The limited permissions granted above are perpetual and will not be revoked by 1EdTech 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
- Content objects can request allocation of an arbitrary number of independent data buckets and access those buckets.
- The runtime system needs no knowledge of the syntax of the information stored in a data bucket.
- The content object must be able to ascertain the available storage per bucket as allocated by the runtime system.
- Data buckets first allocated for one content object can be accessed by other content objects within a defined scope.
- 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.
- The minimum and preferred data bucket requirements for a content object may be explicitly specified as discoverable properties of the content object.
- A content object may declare minimum and preferred data bucket requirements at runtime.
- 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.
- 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.).
- Content objects may access a given data bucket independently of the existence of any other data bucket.
- The runtime system must be able to allocate data bucket storage prior to the content object accessing the buckets.
- 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:
- The specification does not describe any data model for the contents of buckets (e.g., simulation state information).
- Communication between a content object and an external process (e.g., a simulation running outside of the SCO).
- 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).
- Dynamic expansion and contraction of buckets (however, this would be very useful for later functionality).
- 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.
- Offline access to buckets.
- Discoverability of a bucket's data formats.
- How an application profile specifies availability of buckets for multiple content objects.
- How an application profile specifies availability of buckets for multiple learners.
- Defining the outer boundaries for the uniqueness of bucket IDs.
- 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
1.6 References
| [SSP, 04b] | 1EdTech Shareable State Persistence XML Binding v1.0, A.Jackl, B.Towle, 1EdTech Consortium, Inc., June 2004. |
| [SSP, 04c] | 1EdTech Shareable State Persistence Best Practice and Implementation Guide v1.0, A.Jackl, 1EdTech Consortium, Inc., June 2004. |
| [SSP, 04d] | 1EdTech Shareable State Persistence SCORM Application Profile v1.0, A.Jackl, A.Panar, B.Towle, 1EdTech Consortium, Inc., June 2004. |
| [IEEE LOM] | IEEE 1484-12:2002, Standard for Learning Object Metadata, (http://ltsc.ieee.org) |
| [IMSBUND] | Using 1EdTech Content Packaging to Package Instances of LIP and Other 1EdTech Specifications v1.0, B.Olivier, M.McKell, 1EdTech Consortium, Inc., August 2001. |
| [IMSPLID] | 1EdTech Persistent, Location-Independent, Resource Identifier Implementation Handbook v1.0, M.McKell, 1EdTech 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.
2.2 SSP Service Description
The diagram in Figure 2.2 is an illustration 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
2.3.3 Data Elements
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
2.4.3 Data Elements
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
2.5.3 Data Elements
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
2.6.3 Data Elements
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
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
2.8.2.2 Get Allocation Success
2.8.2.3 Get Bucket Identifiers
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
2.9.2.2 Get Data at Offset
2.9.2.3 Set Data
2.9.2.4 Set Data at Offset
2.9.2.5 Append Data
2.9.2.6 Get State
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
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
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
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
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
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
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.
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
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
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
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:
- power on,
- display mode,
- time or deviation from local time (default is current local time),
- current station,
- 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.
- 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.
-
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 | 1EdTech Shareable State Persistence Information Model |
| Editor | Alex Jackl (1EdTech), 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 1EdTech 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:
Revision History
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
I
IEEE 1, 2
1EdTech 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
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
1EdTech Consortium, Inc. ("1EdTech") is publishing the information contained in this 1EdTech Shareable State Persistence Information Model ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.
1EdTech 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.
1EdTech would appreciate receiving your comments and suggestions.
Please contact 1EdTech through our website at http://www.imsglobal.org
Please refer to Document Name: 1EdTech Shareable State Persistence Information Model Revision: 18 June 2004
