IMS Shareable State Persistence Best Practice and Implementation Guide
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 Best Practice and Implementation Guide
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.
2.1 Bucket Identifier Discovery
2.2 Application Example: Assess, Then Review, Activity Sequence
3. Alternate and Appropriate Usage
3.1 Scope of Learners and Content
4.1 Persistence Values
About This Document
List of Contributors
The IMS Shareable State Persistence (SSP) Best Practice and Implementation Guide includes (but is not limited to) 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, Simple Sequencing, etc.).
|[SSP, 04a]||IMS Shareable State Persistence Information Model v1.0, A.Jackl, A.Panar, B.Towle, IMS Global Learning Consortium, Inc., June 2004.|
|[SSP, 04b]||IMS Shareable State Persistence XML Binding v1.0, A.Jackl, B.Towle, 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)|
The Shareable State Persistence specification does not include a method to discover bucket identifiers or specific information about allocated buckets; however, content objects created by a vendor or community of practice can use a predefined identifier for a bucket that would contain information about other buckets. For example, the identifier:
can be used to allocate or inspect a bucket that contains directory information for other buckets used by the objects of the community of practice called "communityName". This directory information may vary between communities of practice, but it could, for instance, include a list of bucket identifiers with, for each bucket, the size, the GUID of the object that created it, and the intended purpose. Another vendor or community of practice might store other data for each bucket it creates inside such a directory bucket. Of course, it is important to choose as an identifier a value that is not likely to be used by anyone else. In the example above, a URN was used as identifier to avoid accidental name collisions.
It is common in learning applications to administer an assessment, evaluate the responses, and then review the assessment with the learner. The assessment itself is one activity. The review is another activity. By storing the learner-specific assessment details in a bucket, the assessment may enable such a review. The sequence would be as follows:
When launched, the assessment attempts to read the assessment results bucket. If such a bucket exists, the assessment clears the content. The assessment updates the content of the bucket with data about which items the user responded to, what the responses were, and so on. How to do this is not defined by the Shareable State Persistence specification, because it will depend on what the creator of the object needs in order to enable the review activity.
Depending on the implementation, the object for the review activity can be the same assessment object, or it could be a separate object that knows about the assessment, but only performs the review task. When the object for the review activity is launched some time after the assessment activity was completed, it attempts to read the bucket with the data stored during the assessment activity. If it finds the data, it then proceeds with the review. If it does not, it suggests a course of action to the user, e.g., do the assessment before attempting the review. Obviously, both the assessment content object and the review content object, if they are different, must agree on the same identifier or collection of identifiers for the review data. It is important to choose identifier values that are not likely to be used by any other objects. Since the identifier will not be read by human beings, but only by content objects, the identifiers can be long and complex.
Where there exists a specification to handle storage of a specific data type , that data should not be stored in SSP Buckets. While one might store assessment data in these buckets, greater interoperability will be achieved if assessment data is stored as structured QTI data. This specification does not replace any other specification. The purpose of this specification is the runtime storage of data, not data for reporting or long-term storage.
The scope of which learners or group of learners can use the bucket and the content objects which can see the bucket can be managed at the application profile level by utilizing the learnerScope and contentScope attributes in the Bucket class. The application profile determines how to use them and its impact on the runtime system.
There can be an "institutional" time limit. This is apart from either a time limit based on a "course" or a "learner". Maximum and minimum periods of persistence are set at the system level and are not in the scope of this specification.
|Title||IMS Shareable State Persistence Best Practice and Implementation Guide|
|Editor||Alex Jackl (IMS)|
|Team Co-Lead||Robert Todd (DigitalThink)|
|Version Date||18 June 2004|
|Summary||This document describes the Shareable State Persistence Best Practice and Implementation Guide.|
|Revision Information||June 2004|
|Purpose||This document has been approved by the IMS Technical Board and is made available for adoption.|
|To register any comments or questions about this specification please visit: http://www.imsglobal.org/developers/ims/imsforum/categories.cfm?catid=21|
IMS Global Learning Consortium, Inc. ("IMS") is publishing the information contained in this IMS Shareable State Persistence Best Practice and Implementation Guide ("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 Best Practice and Implementation Guide Revision: 18 June 2004