Sending SCORM Tracking Data to a IMS TI Outcome Service - Web Services and Service Oriented Architecture

	Web Services and Service Oriented Architecture	Log In
	Sending SCORM Tracking Data to a IMS TI Outcome Service

Browse Space

Add News

Added by Icodeon Customer Support, last edited by Icodeon Customer Support on Aug 30, 2007

When the SCO has completed a session in the SCORM run time environment (RTE), the SCO calls a Terminate() function on the client side API. In the Icodeon RTE the Terminate() function then invokes a Terminate operation on a remote web service, and sends an XML document that represents the data model state of the SCO to the Terminate operation.

In the IMS TI implementation used in the Icodeon SCORM Player, the XML document that has been sent from the RTE is then routed to the host LMS that supports the IMS TI outcome service.

The XML document is an instance of the IEEE 1484.11.3 schema for Content Object Communication Data Model - an XML binding of the SCORM CMI data model. Attached is the documentation and XSD for this XML binding (see the Attachments Tab on this page)

In Icodeon's experience, the Java tools for generating an object model from this (complex) schema are problematic - with the Apache AXIS tools set particularly weak. Icodeon used a combination of Apache AXIS and Castor to achieve results. See discussion here on Icodeon Labs. SO be prepared for some issues in generating Java classes from the XSD...

Comments?

Comments (Hide)

Posted by Icodeon Customer Support at Aug 30, 2007 19:47

Documentation for the Icodeon SCORM Player .NET Edition is here.

Posted by Icodeon Customer Support at Aug 30, 2007 19:49

The Icodeon SCORM Player sends back to the launch LMS (Sakai) an XML instance of the the IEEE 1484.11.3 schema for Content Object Communication Data Model (=COCD) - an XML binding of the SCORM CMI data model.

This is a large datamodel, and typically a persistence layer will not want to persist all fields. Please see the attached Hibernate configuration file used by the Icodeon SCORM Player - only the most commonly used element values from the datamodel are persisted to database fields.

For an initial implementation, Icodeon recommend that Sakai persist these selection of fields also, pending any requirements gathering from the SAKAI community.

Comments?

Posted by Icodeon Customer Support at Sep 01, 2007 23:46

Icodeon have added an XML instance of IEEE 1484.11.3 schema for Content Object Communication Data Model (=COCD) . See attachments tab.

Posted by Icodeon Customer Support at Sep 02, 2007 22:52

Icodeon have added as attachment a small XSD that is used to "wrap" an XML instance of IEEE 1484.11.3 schema for Content Object Communication Data Model (=COCD).

The XSD is for a single element (called "RteDataModelType").

The wrapper element has a number of attributes that are used to "label" with particular COCD XML instance with identifiers. The attributes are currently all listed as "optional" until it has become clear from implementation which ones need to be mandatory.

Example:

<RteDataModelType courseID="myScormPackage" orgID="organizationIdentifier" scoID="itemIdentifier">
<cocd>...</cocd>
</RteDataModelType>

Comments?

Posted by Icodeon Customer Support at Sep 26, 2007 14:54

Comment from Kevin:

Will you be able to join the CC call today and give some indication on progress re the TI results handling for CC?

Posted by Icodeon Customer Support at Nov 30, 2007 17:34

This is what Icodeon suggest for the handling of results schemas.

What Problem are You Trying to Solve?

The problem is that when a "session" with a remote tool (eg Icodeon SCORM Player) has finished, the remote tool needs to send some sort of "result" to the LMS (eg SAKAI). Currently this is sent as

deliveryContextProfile.Ancillary

So the LMS recieves a string or some XML but it has no way of knowing the schema for the XML or the context.

Using the Icodeon SCORM Player as an example, the shema would be:

the IEEE XML binding for the SCORM data model, IEEE 1484.11.3 Content Object Communication DataModel

and the context would be (something like):

this XML document is for learnerID=joe,student for content package item identifier=abc123 and for content package=my_package

If the schema is not defined, the LMS cannot process the XML document returned. If the context is not defined, the LMS does not know what to do with the returned XML document.

Currently in IMS TI both the schema and context are (mostly) undefined for the XML message sent from the remote tool to the outcome service of the LMS.

How are you going to solve the problem?

The deployment descriptor (provided by the remote tool to the LMS) already has a location for providing context information.

toolSettings.Ancillary

Icodeon suggest:

1. Rename the "Ancilliary" elements in both the launch request sent to the remote tool and in the request sent to the LMS Outcome Service. Using the "Ancilliary" elements sounds like we are hijacking a poorly defined field. For the sake of argument we will call the re-named element "Context". (Better suggestions please...).

2. The tool deloyment descriptor will define the XML schema for the child elements of "Context". The launch request sent to the remote tool and the request sent to the LMS Outcome Service will use the same XML schema for the child elements of "Context" (so that we only have one schema to define in the tool deployment descriptor, and so that the request from the LMS to the tool/the request from the tool to the LMS have some symmetry).

3. Add a new element to both the launch request sent to the remote tool and the request sent to the LMS Outcome Service. Lets call this element "Outcome" (Better suggestions please...)

4. In the launch request, the "Outcome" will have a single namespaced child that is the root element of the XML document to be returned. This root element will typically have no children (it is part of the launch request, not the outcome service).

5. In the request to the outcome service, the the "Outcome" will have a single namespaced child that is the root element of the XML document to be returned. This root element will typically now have many descendent elements (it is the results set from the session with the tool).

OK. Enough tech talk. Show me what the XML would look like.

Launch Service Request:

<?xml version="1.0" encoding="utf-8" ?>
<someParentElement>
<context>
    <icodeonToolContext xmlns="http://www.icodeon.com/services/ti">
      <courseID>my course</courseID>
      <skinID>vista</skinID>
      <scoID></scoID>
      <sequencingRequest>resumeAll</sequencingRequest>
    </icodeonToolContext>
</context>
<outcome>
    <cocdType xmlns="http://ltsc.ieee.org/xsd/1484_11_3"/>
</outcome>
</someParentElement>

Outcome Service Request

<?xml version="1.0" encoding="utf-8" ?>
<someParentElement>
<context>
    <icodeonToolContext xmlns="http://www.icodeon.com/services/ti">
      <courseID>my course</courseID>
      <skinID>vista</skinID>
      <scoID>ITEM-34671TR3-YFWC-658Q-T6FE167F3GHTGF99</scoID>
      <sequencingRequest>exitAll</sequencingRequest>
    </icodeonToolContext>
</context>
<outcome>
    <cocdType xmlns="http://ltsc.ieee.org/xsd/1484_11_3">
      <commentsFromLearner>Great remote tool!</commentsfromLearner>
    <completionStatus>completed</successStatus>
      <successStatus>passed</successStatus>
    </cocdType>
</outcome>
</someParentElement>

complete
passed

Note that now we have context and schema, and that the launch service request and the outcome service request have some symmetry - so that we only need to defined schemas once, and not one schema each for launch and outcome servivce requests.

What happends now?

Icodeon and SAKAI to test an implementation of this design.

Comments?

Posted by Icodeon Customer Support at Nov 30, 2007 17:48; last updated at Nov 30, 2007 18:35

Add Comment

LTI 2 Implementation

Contextual Information in a Launch Request