Improve SCORM 2004 Support
| Improve SCORM 2004 Support | |
|---|---|
| Project state | Community Bonding |
| Tracker issue | MDL-7068 |
| Discussion | |
| Assignee | Mayank Gupta |
Moodle 2.3
GSOC '12
Overview
Abstract
This document is the specification for Improving SCORM 2004 Support in Moodle, a Google Summer Of Code (GSoC) 2012 project. The goal of this project is to work towards achieving full SCORM 2004 4th Edition compliance in Moodle without the need of any external plugins, that is, improving the support for SCORM 2004 content packages in Moodle.
The project mentor is Dan Marsden and the program administrator is Michael de Raadt.
Context
The project will improve the SCORM 2004 support in Moodle by using the SCORM Test Harness. The automated test framework will help by automating the execution of SCORM 2004 tests in Moodle and thus, will help in identify the issues with SCORM 2004 support in Moodle. This project will also indirectly help in improving the SCORM Test Harness itself, as by getting the Test Harness into action bugs would be identified and fixed in the Test Harness.
In order for Moodle to be SCORM 2004 4th Edition compliant and pass all the 189 ADL SCORM 2004 conformance test packages, it needs to adhere to the specifications laid down by ADL SCORM 2004 4th Edition. The specification can be divided into three sub-specifications as -
- Content Aggregation Model (CAM)
- The Run-Time Environment (RTE)
- Sequencing and Navigation specification (SN)
Content Aggregation Model
The Content Aggregation Model sub-specification of SCORM 2004 4th Edition specifies how SCORM 2004 content developers should package their content so that the packages can be imported into the LMS. According to SCORM 2004 specification the content developers should package the content in a self-contained directory or a ZIP file which is also called a Package Interchange File (PIF).
SCORM 2004 specifies that the packaged ZIP file should always contain an XML file with the name - 'imsmanifest.xml' . This imsmanifest.xml file also called the manifest file should be located in the root of the ZIP file. The content developers have to make sure that this manifest file contains all the information the LMS would need to successfully deliver the SCORM 2004 content to the content viewers.
The manifest file divides the course into one or more parts called SCOs, which in other words represents the activity tree for the course content. The manifest file contains an XML representation of the activity tree of the package, information about how to launch each SCO, and optional metadata that would describe the course and its part. As a LMS it is the responsibility of Moodle's "SCORM module's code" to correctly parse the manifest file, store all the required information of the package in the database.
Current State
The file /mod/scorm/datamodels/scormlib.php has the code that parses the manifest file. Currently this file is not able to parse all the CAM definitions according to SCORM 2004 4th Edition Specifications. For instance, the current code of scormlib.php is not able to parse correctly the ADLCP:DATA, and ADLCP:MAP sections of the manifest file. These sections define the Inter-SCO Storage Data Model Extension; that was introduced in ADL SCORM 2004 4th Edition specification. Other sections of the manifest file that scormlib.php fails to parse successfully will be identified and resolved during the course of the project by running the SCORM Test Harness for individual SCORM 2004 conformance packages.
Run-Time Environment
The Run-Time Environment (RTE) sub-specification of SCORM 2004 specification specifies how the LMS should launch the content package within itself. The RTE states that the SCORM 2004 content package should be launched within Moodle in a web browser as a new window or within a frameset in the same window. The RTE specification specifies that all the content in the SCORM 2004 package should be web deliverable and is always launched in a web browser. It also specifies that the LMS should launch one SCO at a time.
In order to allow communication between the SCORM 2004 content package more specifically the launched SCO of the content package and the LMS; the LMS should provide an ECMAScript (JavaScript) API through which the SCO can communicate with it. All communication between the SCO and the LMS can take place through this JavaScript API only, that is, the content package can by no means communicate with the LMS through form posts, database access (read/write), web services or any other mechanism. As a SCO can communicate only through the JavaScript API, the LMS provides the JavaScript object of the API at a specific location within the browsers' DOM. This API object has the special name of 'API_1484_11' for SCORM 2004. It is the responsibility of the content/SCO to locate this API object and then use it for all the communications it needs to do with the LMS. RTE specifies that only the SCO can initiate the communication as the LMS acts as a passive entity which is simply responding to the API calls made by the SCO.
The API provides a set of eight functions that permit the exchange of data with the LMS. These functions are -
| Function | Return Type | Remarks |
|---|---|---|
| Initialize( “” ) | bool | it indicates to the LMS that the content would like to begin a communication session. |
| Terminate( “” ) | bool | it indicates to the LMS that the content has finished communicating |
| GetValue( element : CMIElement ) | string | it allows the SCO/content to data from the LMS |
| SetValue( element : CMIElement, value : string) | string | it allows the SCO/content to persist data to the LMS. |
| Commit( “” ) | bool | it is used by the SCO/content to signal the LMS that a significant chuck of data has been saved and that the LMS should ensure the data is properly persisted |
| GetLastError() | CMIErrorCode | it allows to determing if the last SCORM API call caused an error |
| GetErrorString( errorCode : CMIErrorCode ) | string | it return a textual description of what the passed error code means |
| GetDiagnostic( errocCode : CMIErrorCode ) | string | it returns detailed information about the prior error that can be useful in detecting the problem. |
The Computer Managed Instruction or CMI data model provides a list of data elements which can be read and written using the API. Each data model element has its own meaning.
Every SCO in a content package has its own set of run-time data. These data model elements have different values for different SCOs within a content package. Before SCORM 2004 4th edition the RTE data model definitions came into existence these data model elements could not be shared across SCOs of the same or different content package. When the content user or learner starts a new attempt on a SCO, the data model element's values are reset to the default values at the start of the new attempt. These data models have different default values and can be of either read-only or both read and write type.
Some examples SCORM 2004 RTE data model elements include the cmi.completion_status element - that saves the status of the SCO (completed or incomplete), cmi.success_status (passed or failed), the score of the learner, a bookmark to track the learner’s location, and the total amount of time the learner spent in the SCO.
However, apart from the non-sharable data model elements defined before, the SCORM 2004 4th Edition RTE Data Model definitions define the adl.data data model elements that provide the unique ability to share sets of data across the SCOs.
Current State
The file /mod/scorm/datamodels/scorm_13.js.php has the code to deal with the data model elements that a SCO would require. This code needs to be extended to support the data models defined by the SCORM 2004 4th Edition Run-Time Envirnoment Data Model definition. These data model elements mainly include adl.data elements - Inter-SCO Storage Data Model Extension. Some progress has already been made on the tracker issue MDL-28805 - ADL TEST: Data Model Implementation (DMI). While trying to fix the mentioned bug, a number of related issues that needed to be resolved before the bug MDL-28805 could be closed were identified. These bugs were - MDL-30666, MDL-30576, MDL-30577, MDL-30578, MDL-30579, MDL-30645. As mentioned above, during the course of the project the data model code would be extended to support SCORM 2004 4th Edition Run-Time Environment Data Model definitions and other 'buggy areas' would be identified by running the SCORM Test Harness for SCORM 2004 Conformance packages issues would be reported and patches will be provided.
The Sequencing and Navigation sub-specification of SCORM 2004 4th Edition specification allows content developers to override the default navigation of SCOs and enable them to govern how the content user/learner is allowed to navigate between various SCOs in the content package and also how the progress data is rolled up to the course level of the content package.
The content developers lay down the sequencing rules in the imsmanifest.xml file or the manifest file, in the root directory of the PIF. These rules in-turn determine which navigational controls should the LMS provide to the content user/learner, that is, whether or not a navigable table of contents (TOC) should be provided to the learner or just the previous/next buttons should be provided to the learner to navigate from one SCO to another in a linear sequence of SCOs. By specifying sequencing and navigation rules in the manifest file the content developer can also specify that certain conditions like some SCOs/activities must be completed before the learner can navigate to the some other SCO/activity. The content developer by adhering to the SCORM 2004 Sequence and Navigation specification can also apply a gradient weight to some parts or activities of the content package, that is, if some higher weighted activities when completed by the learner would add more to his total score than when he completes a relatively lower weighted activity. Not only this, the Sequencing and Navigation specifications can allow the content developer to randomly select a different subset of SCOs each time a new attempt is made. The SN specification also powers the content developer to forcibly take the learner to initial SCO (that would generally have some instructions).
Every activity of a SCORM 2004 content package has a tracking data and a sequencing definition associated with it. The tracking data has the information about the current state of the activity that is, the score of the learner, the status, etc. The sequencing definition is the set of rules that defines which activity should follow next, that is, which activity should be presented to the learner after he completes the activity depending upon the tracking data of the activity.
The sequencing definition model rules can be subdivided as -
- Sequencing Control Modes – these define the type of navigation allowed to the learner, that is navigation through the TOC or linear navigation via previous/next buttons.
- Constrain Choice Controls – Restrict the activities that the user may select from the table of contents.
- Sequencing Rules – Specify if-then conditions that determine which activities are available for delivery and which activity should be delivered next.
- Limit Conditions – Provide limits on the number of times activities can be attempted.
- Rollup Rules – Specify if-then conditions that determine how status is rolled up to clusters throughout the activity tree.
- Rollup Controls – Determine which activities participate in status rollup and how their status is weighted in relation to other activities.
- Rollup Consideration Controls – Provide more precise control over status rollup than do the rollup controls.
- Objectives – Provide a way to track the status of individual learning objectives and share this status across activities. Objectives are often overloaded and used as variables to control sequencing actions.
- Selection Controls – Provide a way to specify that only a random subset of the available activities should be delivered.
- Randomization Controls - Shuffle the order of the activities to be delivered.
- Delivery Controls – Allow for non-communicative content to be delivered and sequenced.
- Completion Threshold Controls – Allow the tracking of completion percentage. This was introduced in the SCORM 2004 4th Edition specification.
- Navigation Controls - Control which navigational UI elements should be presented by the LMS.
Current State
The code that currently implements Sequencing and Navigation specification of ADL SCORM 2004 specification is in the file /mod/scorm/datamodels/sequencinglib.php.
The SCORM module currently supports activity restriction, that is, if the content developer has restricted some activities to not to be navigable directly by selecting from the table of contents, the TOC does not allow the learner to do so. Though, the TOC is correctly rendered, there are issues like when the initial SCO/activity is complete and it triggers the continue event, the next SCO is not launched, rather the same initial SCO is launched again. In some cases the SCO uses adl.nav.request to navigate to a different location, this also causes the same issue of the SCO being launched again. These are just a couple of the many issues that are currently there in the SCORM module to support SCORM 2004 Sequencing and Navigation specification specification.
The bug that holds the next SCO from being launched will be the first issue that would be fixed as the part of the project to improve SCORM 2004 support in Moodle, because, this bug will prevent other SCORM 2004 test packages to load successfuly and thus, would not allow the SCORM 2004 conformance packages to run and test successfully. A probable fix for the issue would be to store the structure so that code can continue but learner cannot use continue, TOC, links, etc. The above can be implemented by shifting the URLs of the SCO to the id attribute of the spans HTML tags and then making JavaScript to fetch the ids and use them as URLs.
Work is already being done to rewrite the function scorm_get_toc - MDL-32835.
The SCORM Test Harness will help in identifying other Sequencing and Navigation issues in the SCORM module by helping to run the SCORM 2004 conformance test packages automatically.
Schedule of Deliverables
May 31st - 5th June: Fix SN bug that prevents SCOs from loading, and potentially- ADL Test: CM-02, ADL Test: CM-03, and ADL Test: DDM.
6th - 17th June: Fix SCORM 2004 bugs, potentially- ADL Test: DMI, ADL Test: DMB, ADL Test: CM-04, ADL Test: T-01
18th - 27th June: Fix SCORM 2004 bugs, potentially- ADL Test: CO-01, ADL Test: CO-02, ADL Test: CO-03, ADL Test: CT-01
27th June - 8th July: Fix SCORM 2004 bugs, potentially- ADL Test: MS-01, MS-02, MS-03, OB-01, CT-02
9th - 15th July: Fix SCORM 2004 bugs, potentially- ADL Test: RU-01, ADL Test: RU-02, ADL Test: RU-03, ADL Test: RU-04
This will be the midterm evaluation target - A detailed report on the then status of SCORM 2004 support in Moodle, mentioning all improvements and results of the closed issues to the Moodle Community.
16th July - 22nd July: Fix SCORM 2004 bugs, potentially- ADL Test: SX-02, ADL Test: SX-03, ADL Test: SX-04, CM-05
23rd July - 1st August: Fix SCORM 2004 bugs, potentially- ADL Test: CM-06, ADL Test: CM-07, ADL Test: CO-05, ADL Test: CO-06, ADL Test: CO-07
2nd - 12th August: Fix SCORM 2004 bugs, potentially- ADL Test: CT-03, ADL Test: CT-04, ADL Test: CT-05, CM-08, ADL Test: CM-09
13th - 19th August: Fix SCORM 2004 bugs, potentially- ADL Test: OB-02, ADL Test: OB-03, ADL Test: 0B-04, ADL Test: RU-05, SX-05
