ࡱ > Y _, a, , , , ,
, , ,
, , , , , , , , , , , , , , , , , , , , !, ", #, $, %, &, ', (, ), *, +, ,, -, ., /, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, :, ;, <, =, >, ?, @, A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, [, \, ], ^, r[ bjbj
7 h h P P D 7 7 7 {! 7 F G" 6 }# }# }# # U, ;- D - $ mF oF oF oF oF oF oF $
I K F - + U, - - F }# # F ;7 ;7 ;7 -
}# ( # mF ;7 - mF ;7 ;7 n @ T qB # !a 7 3 A YF F 0 F A L ;7 L @ qB L qB - - ;7 - - - - - F F ;7 - - - F - - - - L - - - - - - - - - :
How to Make SCORMs Simple Sequencing Model Simple Again
A Brief Technical Proposal for Upgrading SCORM Sequencing & Navigation to Make it More Reliable and Easier to Implement
Contents
TOC \h \z \t "Heading 1,1" HYPERLINK \l "_Toc197755607"Executive Summary PAGEREF _Toc197755607 \h 2
HYPERLINK \l "_Toc197755608"Introduction PAGEREF _Toc197755608 \h 3
HYPERLINK \l "_Toc197755609"Problem Statement PAGEREF _Toc197755609 \h 3
HYPERLINK \l "_Toc197755610"Specific Problem Areas PAGEREF _Toc197755610 \h 4
HYPERLINK \l "_Toc197755611"Mark Ewers ECMAScript Solution PAGEREF _Toc197755611 \h 4
HYPERLINK \l "_Toc197755612"Implementation PAGEREF _Toc197755612 \h 6
HYPERLINK \l "_Toc197755613"Summary PAGEREF _Toc197755613 \h 8
Executive Summary
The 2004 version of the Sharable Content Object Reference Model (SCORM) promised to provide a way to create interoperability and durability in training products. While the theories and concepts have incredible potential and demonstrate some truly innovative design concepts the technical implementation has been problematic for many adopters. The concrete implementations of SCORM sequencing and navigation systems are fragile. It is far too easy for a content developer to create a content package that does not work the way the expected - or, even worse, works differently when executed on different implementations.
In this white paper, I examine a radical shift in how a SCORM sequencing system could be constructed and present a concept that I believe would be much less prone to the varying interpretations of the current model. This new model is based on using embedded ECMAScript code with an event based model to replace the current sequencing rules. This kind of programming model will be much more familiar to developers and is proven to work reliably in other systems.
The concept is for the content developer to embed ECMAScript code into the manifest so that the Learning Management System (LMS) will execute that code when it is about to sequence a new content object. Instead of having the LMS select the content based on a set of rules, the ECMAScript will tell it which content object to deliver next using logic provided by the content creator.
This effectively eliminates the possibility that the content will work differently on various LMS implementations.
Introduction
Since its inception, SCORM has been heralded as the specification that would bring order to the chaos of interactive courseware development. In some respects it has lived up to these expectations. The ADL vision is to bring the high level ilities to the training and education market. These include:
Interoperability - use components in other systems
Accessibility - locate and access components
Reusability - reuse components in multiple applications
Durability - withstand technology changes over time
Maintainability - withstand content evolution
Adaptability - ability to change to user needs
The ADL Initiative has successfully achieved a broad industry adoption of the SCORM 1.2 specification both in the USA and abroad and has ratified it as an IEEE standard. Version 1.2 worked fairly well and began to deliver on some of the promises of the ilities but lacked one very substantial feature. There was no way to sequence a set of reused content objects in any order other than linear.
Problem Statement
The difficulty with SCORM 2004 is that the IMS Simple Sequencing extensions are just not simple. In order to deploy sequenced content the LMS vendor must develop a sequencing engine. While ADL has provided a reference implementation and a sample pseudo code description of the logic, this is still a substantial task. It turns out that every sequencing engine behaves slightly differently.
The second part of the complexity is in the XML extensions to the SCORM manifest. The content vendor is responsible for creating a manifest that tells the LMS sequencing engine how to deploy the content. This XML grammar is complex, and the implementation logic is not intuitive. XML is a data representation language, not a logic or programming language. This makes it easy for a content vendor to develop a manifest that instructs the LMS to do something the content vendor did not intend. This error prone XML grammar problem is compounded by the fact that LMS sequencing engines are different. So, a faulty manifest may work correctly on one LMS but not on the next.
In addition to the complexity, SCORM goes to great lengths to ensure that each content object is isolated from other objects. The reason is to help ensure that the content will be reusable in different scenarios. It accomplishes this goal by preventing the content developer from creating dependencies between content objects. However, this isolation goes too far. There is no way to determine what actions a learner has performed in a previous content object. This has caused the content vendors to use the Learning Objectives as data passing variables instead of tracking learning objective status as they were intended. Using standardized fields for something other than their intended use leads to fragile implementations and inconsistent reporting data.
While all the runtime data is encapsulated, the navigation request system does not insulate one content object from the others. SCORM defines and allows a navigation mode called choice where one content object can tell the LMS which content object should come next. This occurs by the first content object specifying the specific name of then next. This effectively breaks encapsulation and makes the content object far less reusable. Worse, the LMS vendors try very hard to allow the reuse which means that they may disregard navigation requests if the LMS thinks they are inappropriate.
The last factor to compound the problem is that this arrangement leaves no clear responsibility. Content vendors say, My content doesnt work because of a defect in this LMS, while the LMS vendors say, This content doesnt work because of a defect in the content. The customer ends up caught in the middle and frustrated.
Specific Problem Areas
Simple sequencing uses a data representation language to describe logic. It must use a logic language to express logic.
LMS vendors can interpret SCORM requirements differently. The specification must remove the potential for differences in interpretation.
SCORM encapsulates all runtime data inside each content object so that this data cannot be used to make sequencing and navigation decisions. While encapsulation of one content object to the next is required for reusability, the sequencing logic must be able to read any runtime data from any content object in the current package.
SCORM allows content objects to specify the content object to be delivered next through choice navigation. This breaks encapsulation and prevents the content object from being reused in a different context.
A sequencing implementation requires collaboration between content vendors and LMS vendors which leads to confusion about who should correct an error when it occurs. Sequencing implementations must be the sole responsibility of only one party. Since content vendors are the domain experts in the content, sequencing logic must be their responsibility.
Mark Ewers ECMAScript Solution
The solution to this problem is to reduce the complexity and establish the roles of the content vendor and the LMS vendor more clearly. The complexity is the use of a data language to describe instructions to a sequencing engine. Instead of having the content vendor attempt to supply instructions to an LMS vendors sequencing engine, I propose that SCORM use an event-based programming model with a scripting language like ECMAScript.
ECMAScript is an international standard and one of the most used programming languages in the world. ECMAScript has been successfully integrated with other XML grammars such as XHTML, Adobe MXML, and Microsoft XAML. SCORM can adopt the same approach and allow the content vendor to insert a element into the manifest that contains ECMAScript code to sequence the content. Each element would be associated with a specific event in the content delivery lifecycle. Figure 1 lists the events by object type. I have identified four organization level events and four content object level events. The diagram in Figure 2 shows the sequence of events as they would occur during execution of a content package.
Other implementations of ECMAScript that have been successful have combined the scripting language with a Document Object Model (DOM) that can be manipulated from the scripting code. I propose a similar approach where the DOM consists of all the content objects in the SCORM package and their associated runtime data. This will allow the content vendor to develop scripting code that is embedded in the manifest (not content object) and that can evaluate the execution state of any content object in the package and launch the appropriate content object next. Here is an example of how a content vendor may provide this logic:
In this example, the content author has used a script for the onterminate event for a content object. The content author has used a conditional statement to evaluate if the test score is greater than 80% by comparing the cmi.scaled_score value from its runtime data. If the score was high enough, the lesson summary is returned, otherwise the remediation content object is returned.
Benefit - Logical Simplicity
The approach uses a programming language to express the logic of the sequencing decisions. This is much simpler to do than using XML data structures to provide input to a sequencing engine. ECMAScript is widely adopted and will be familiar to developers.
Benefit - No Room for Interpretations
This model removes the complex decision making that LMS vendors are required to support now. The next content object to deliver is specified by the return value of the event handler code. If no code is present or the code does not return a content object then the LMS delivers the current content objects next sibling. If there are no siblings, the LMS exits the parent.
Benefit - Encapsulation
This solution provides full data encapsulation from one content object to the next. The only code that has visibility into more than one content object is located in the manifest. This ensures that the content object is reusable and adaptable. To reuse and object you simply create new sequencing event handlers in the new manifest. Since you have to make a new manifest anyway, this approach makes sense.
Benefit - Simple Integration
Since the burden on the LMS vendor is greatly reduced, the potential for integration challenges from one LMS to the next is also greatly reduced. The sequencing logic is now in the hands of the content vendor who can make the content work any way they choose. Reusability will be much higher and content will be much more reliable and portable.
Implementation
The details of implementation are much simpler than the current sequencing model since the actual sequencing logic is embedded into the event handlers instead of the LMS sequencing engine. However, this solution does still require an Activity Tree (AT).
While the AT described in the current version of SCORM is merely a reference for how to structure the LMSs private data, the AT proposed here is a public API exposed to the ECMAScript event handlers in the manifest. Since the event handlers can determine state information about each content object, the sequencing logic can be dynamic based on the learners current progress.
The AT is a hierarchal data structure based on a parent child relationship pattern very similar to the Composite pattern described in Design Patterns by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides (ISBN 0-201-63361-2). The AT is based on the XML structure of the element and its children from the manifest. Figure 3 shows a UML object model of the objects in the AT. Since these objects are arranged into a Composite object, it is a simple matter to walk the tree of objects to find any specific data element needed to implement the sequencing logic required. Each node in the tree has data fields to store the results of roll-up scores and completion status information. However, this is a significant departure from the SCORM 2004 implementation in that it is the sole responsibility of the event handlers in the manifest to control these values. The LMS is only responsible for storing the values set by the manifest.
At the leaf nodes in the tree there are SCO or Asset objects. While Assets have only the basic success and completion status fields like all nodes, the SCO has something more. Because the SCO reports back runtime data to the LMS during execution, this data is accessible through the SCO object. The SCO object has a data field that references the same API used by the SCO to report the CMI data model. The only difference is that all data in the CMI data model is read-only from the manifest. In Figure 4 you can see how this hierarchy is arranged to allow access to the API and the CMI data model from the leaf SCO objects.
It is the responsibility of the LMS to call the proper event handler. This model defines eight events. There are events for the start, suspend, resume, and end of an or SCO. The convention is that the event handler will return a reference to the SCO that should be launched next. If it returns a null, then the LMS will end the session.
This is a powerfully different concept than the current sequencing modes. The LMS does not determine what SCO is launched; it launches the SCO returned by the event handler. This means the event handler for resuming a SCO could direct the learner to a completely different SCO or a learner could be force to repeat SCO, skip SCOs, or any number of non-linear or complex branching operations. An example of one potential flow pattern is shown in figure 5. Attachment 1shows the manifest file that corresponds to the flow diagram in figure 5.
Attachment 1: Sample Manifest XML that corresponds to the diagram in Figure 5.
ADL SCORM
2.0
SCORM 2.0 Event-Based Sequencing Model
-
Introduction
-
Pre Test
-
Primary Instructional Content
-
Introduction
Summary
The proposed solution to the problems with the current Simple Sequencing model addresses essentially all of the current difficulties and reduces the level of effort required to build and integrate courseware products. Using ECMAScript navigation events in the manifest ensures the benefits of Simplicity, Accountability, Encapsulation, and Integration.
Since this proposed solution does not change the interface between a content object and the LMS, it will not make any existing content obsolete. All that needs be done to convert existing content to this format is to add navigation event handlers to the manifest.
Adopting this proposal will empower content developers to dramatically increase the level of interactivity and deliver much more highly engaging content that can adapt to the needs of each learner.
About the Author
Mark Ewer is the lead software developer at Logistic Services International. Mark is responsible for the development of software tools used to produce thousands of hours of SCORM compatible content in a fast-paced and high volume production environment. You can find out more about Mark through his LinkedIn profile at HYPERLINK "http://www.linkedin.com/in/markewer"http://www.linkedin.com/in/markewer or by contacting him directly at HYPERLINK "mailto:MEwer@lsijax.com"MEwer@lsijax.com.
Friday, May 02, 2008
Friday, May 02, 2008
LSI, Inc
6200 Lake Gray Blvd.
Jacksonville, FL 32244
904-779-2100
HYPERLINK "http://www.lsijax.com"http://www.lsijax.com
Mark Ewer
Technology Director and Lead Software Architect
HYPERLINK "mailto:MEwer@lsijax.com"MarkEwer@lsijax.com
Event ElementEvent NameOrganizationonstartonsuspendonresumeonterminateContent ObjectonstartonsuspendonresumeonterminateFigure 1 Event Names by Object
Figure 2 Temporal Model Relationships for a Package with Three SCOs.
Figure 3 Activity Tree Object Model
Figure 4: Activity Tree Object Hierarchy a Composite Design Pattern Implementation
Figure 5: Event based flow example.
< = ³sea]aRNRFBF ha j ha Uh j ha ha Uhvx hLz h CJ OJ QJ ^J aJ ;j ha ha 5CJ OJ QJ U^J aJ mH nH tHu$j ha ha UmH nH tHu h:v 6CJ OJ QJ ^J aJ hT@ 6CJ OJ QJ ^J aJ h:v 5CJ OJ QJ ^J aJ hQ h hQ 5CJ8 OJ QJ ^J aJ8 hQ h CJ, h 5CJ8 OJ QJ ^J aJ8 < = 7 *
3 gd,
gdvx gd:v $a$gd:v $a$gdQ gdQ $a$gd gd 1 2 3 4 5 6 7 8 T U a b c } ~
$
ײײwײ #j ha UmH nH u#j} ha UmH nH uha $hZ= 5CJ OJ QJ aJ mH nH u j ha Uh5 mH nH u #j ha UmH nH uj ha UmH nH uhZ= mH nH u h/Y hZ= 0J mH nH u +$
%
&
'
(
)
*
+
G
H
g
h
i
˸˴˦ޛ˸˴˦ޛw˸˴˦ޛ #jq ha UmH nH u#j ha UmH nH uhZ= mH nH u h/Y hZ= 0J mH nH uha $hZ= 5CJ OJ QJ aJ mH nH u j ha Uh5 mH nH u j ha UmH nH u#jw ha UmH nH u ' ! P
T
r f g t # ' T X x ] p ˸{{{{wssss hJ7> hvx h#x: h` h h{j h= h= hZ= hm ho=M h{j hu hLz j ha CJ OJ QJ U$hZ= 5CJ OJ QJ aJ mH nH u j ha Uh5 mH nH u j ha UmH nH u#j ha UmH nH u +3
r s g t = q ^ p gdvx gd`
&