Representing SCO Behavior

Mark J. Norton

May 16, 2001

Two kinds of behavior need to be represented in the SCO’s: interactive and sequencing. In the current SCORM model, interactive behavior is described using a combination of HTML tags and a run time API implemented using a JavaScript based adaptor. SCORM 1.1 also indicates that an LMS is responsible for managing sequencing and navigation between SCO’s based on the Content Structure Format (CSF).

Initial implementations of the SCORM show signs of subverting the architecture and protocols established by it. Reasons for this may be that the communication link required by the model is difficult to implement and might violate security provisions in some networks. Efficiency may also be impacted. It might also represent a major deviation for existing server based learning systems. Early versions of web browsers, still in use, do not implement the Document Object Model, or implement it in a non-standard way. This mays a JavaScript based API very difficult to implement.

This paper proposes a alternative approach to handling the rutime behavior of SCOs. It eliminates the API and replaces it with a data driven behavior model implemented by Learning Sturctures. An SCO would be initialized and prepared in the server environment first. It is here that some of the SCO’s behavior is handled. Instead of a communication link that comes and goes as SCOs are downloaded to a client, only the user interface and interactive elements of the SCO are sent to the learner. When the interaction is complete, state and other information is sent back using conventional CGI encoding.

Interactive Behavior

Interactive behavior refers to the internal behavior of the SCO. It includes initialization of the object, conditional display of content, information to be embedded from external sources, display formatting, definition of interative elements, capturing information supplied by the user, and termination signal (goto next or exit).

Client to server communication outside of normal HTTP transactions is complicated and may violate some security systems such as firewalls. Some or all of the interactive behavior can be done on the server prior to responding to an HTTP request from the client. Currently, the SCORM model defines eight LMS API functions based on the older AICC runtime interface. Let’s examine these against a server side initialization approach.

Each SCO is a self-contained learning object which contains information about raw content times associated with it and how they should be presented to the user. We should note in passing that even presentational behavior may need to be modified at run time due to accessibility needs.

SCORM defines an LMSInitialize() function which must be invoked before any other API calls. The SCORM indicates that this can be used to set up a communication channel. Server side initialization may still need to initialize an SCO, but will do so automatically. No communication channel is needed. Certain side effects may be defined, perhaps controlled by meta-data flags: record-start-time, etc.

SCORM defines an LMSFinish() function which must be invoked at when the SCO is done. This is not a typical HTML operation, and must be specially defined in JavaScript using onExit() or similar. As an alternative, SCO cleanup could be done when the request for the next SCO or exit indicator is received.

It seems that LMSGetValue() is the critical point in determining SCO behavior. In order to provide some flexibility concerning data models, some discovery is needed to explore data element available. Data gotten could be embedded directly in the SCO display form, or could be used to compute the display form. Data elements might also need to be combined. All of these needs call for some sort of programming language. SCORM suggests that client side JavaScript will provide this.

While it is true that JavaScript is currently implemented in all of the major browsers, it is outside of the control of the SCORM specification. A manufacturer of browsers (Microsoft, for example) could decide at any time to abandon JavaScript in favor of another embedded language. While this is unlikely, the model could be made stronger by assuming control of SCO initialization by implementing behavior server side. Client side behavior could remain outside of the model and change as technology changes.

The LMSGetValue() function could be used to embed a particular value in the UI presentation (test score, for example). Or it could be used in an expression to create conditional display of content. A variable substitution mechamism could be used to insert a value using the same value naming scheme defined by SCORM. Conditional content display could still be done using JavaScript or an expression syntax could be defined.

Conditional content display illustrates that some form of programming is needed within the SCO itself. Who is likely to do this programming? Likely it will be the developers of the LMS and Authoring tools. Authors will likely be given choices of display style (etc), which might require the generation of code to be embedded in a SCO. Given these pratical considerations, these types of choices could be added to a particular version of a learning structure and invoked using data either in the CSF meta-data, or embedded in the SCO itself.

HTTP defines a means of transferring variable values and state from the client to the server using the CGI encoding method. CGI variables would be used either to control state and sequencing of SCO’s, or to return data to be recorded in some data repository (TBD). State variables could be prefixed as system.foo.bar, while variables to be recorded would use the CMI variable naming scheme.

SCORM defines a set of error handling functions to get error codes and associated error strings. If display content is initialized at the server, appropriate error messages could be formatted and returned to the user based on the error situation. Error codes are largely based on programming, authoring, or access errors.


Sequencing Behavior

The LMS manages sequencing and navigation between SCOs based on the Content Structure Format (CSF). This means that the LMS must interpret the CSF to determine sequencing and presentation order. Actual sequencing of SCOs is therefore implementation dependent.

A method similar or equivalent to Learning Structures is proposed to define and implement sequencing, navigation, learning style, and pedagogy. Each CSF contains a collection of SCOs which is sequenced by a particular Learning Structure, defined by a CSF meta-data type. This type indicates which structure should be used. The structure defines and formats the user interface needed to navigate the collection of SCOs based on the learning style it implements. The structure is also responsible for intializing the SCO before being returned to the client for presentation, as defined above.

Learning Structures of this type have been effectively implemented and used to create several major learning environments by the author during his time at TechOnLine and MicroMentor. Companies like Motorola, Hitachi, Mentor Graphics, Corning Glass, and Otis Elevator have all used them in on-line corporate university settings.

Note that learning structures can also be created which assemble SCOs dynamically, based on user choice, assessment, learning objectives, and other inputs.


Summary

This approach describes a means of representing individual and aggregated SCOs in which presentation, interaction, and sequencing behavior can be represented in a portable and consistent manner. It requires that an aggregate SCO be associated with a particular version of a particular learning structure. It moves all SCO behavior out of the objects themselves into the learning structure driven by data supplied by the learning objects. This not only allows SCOs to be portable, but also permits learning structures to be implemented using targeted system resources for efficiency and avoids problems with client-server communication links.