IMS specifies buckets
Wilbert Kraan, CETIS staff
April 08, 2004

Data buckets, that is, in the public draft of the new Sharable State Persistence specification. Its function is as simple as it is useful: it provides a means for learning objects (specifically of the SCORM persuasion) to store data about the state they were left in. These buckets can then accessed by other objects, who can act on the data.

What drove the development of IMS Sharable State Persistence is as refreshingly simple as the spec itself: a learner starts with object A, which teaches her a couple of aspects of a topic, and assesses her performance as well. She is then invited, whenever ready, to go to another learning object B to review how she's been doing, and get some hints at how to improve. Trouble is, there has been no standardised way for object B to know what a learner did in object A.

Hence the buckets: agreed bits of storage space on the Virtual Learning Environment (VLE) server that can be accessed by a predefined range of objects. With them, object A can dump whatever data it wants in whatever form it likes into a bucket, and object B can start looking for the bucket, and grok the contents. As long as object B knows about how to find the bucket, and what it is supposed to do with the data that it finds there, it can adjust its own contents accordingly.

Neither data format, nor ways of finding or identifying the buckets are specified. Neither does it specify for how long the buckets or the data in them should be kept. All that it does specify is how to negotiate the size of the bucket an object requires in such a way that it can be figured out either when the object is launched, or when examining the object. It also specifically indicates that SSP buckets are not to be used for specifications that already have provisions for persisting data of particular kinds: IMS Simple Sequencing (SS) and Question and Test Interoperability (QTI), for example. IMS Learning Design is not mentioned but can be presumed excluded, since it has some provisions of its own.

What it is specifically aimed at is simulations, particularly those that are contained in a Sharable Content Object (SCO - the SCORM learning object format).
Hence the fact that the IMS specification is made available with a SCORM profile of it, at the same time.

This SCORM profile specifies a whole lot more: how to indicate bucket size and persistence requirements in a SCO manifest, for example, but also how each object should set or get data from the buckets on the VLE. That communication is taken care of by an abstract Application Programming Interface (API) that is bound to Ecmascript (JavaScript). Put bluntly, an SSP enabled SCO talks to a VLE in exactly the same way as all other SCOs, just with a few more commands.


The public draft of IMS Sharable State Persistence.