1 / 40

The Scorm Runtime Environment An Overview By Chris Poole

The Scorm Runtime Environment An Overview By Chris Poole. The SCORM is based directly on the run-time environment functionality defined in AICC’s CMI001 Guidelines for Interoperability.

lew
Download Presentation

The Scorm Runtime Environment An Overview By Chris Poole

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Scorm Runtime Environment An Overview By Chris Poole Chris Poole: Senior Content Developer

  2. The SCORM is based directly on the run-time environment functionality defined in AICC’s CMI001 Guidelines for Interoperability Chris Poole: Senior Content Developer

  3. ADL collaborated with AICC members and participants to develop a common Launch and API specification and to adopt Web-based data elements Chris Poole: Senior Content Developer

  4. One of the main goals of the SCORM is interoperable content • This means we have a number of problems to solve • How does the LMS start the learning object • How does the LMS and learning object communicate • What language do they speak • What do they say Chris Poole: Senior Content Developer

  5. To address these problems the runtime environment uses three components: • Launch • Application Program Interface (API) • Data Model Chris Poole: Senior Content Developer

  6. The Launch Mechanism • Defines the procedures and responsibilities for establishment of communication between the object and the LMS • Standardises the communication protocols by the use of an API Chris Poole: Senior Content Developer

  7. Launch • What can we launch? • SCO’s • Assets Chris Poole: Senior Content Developer

  8. The LMS must • Launch the SCO in a browser window that is • a child window or a child frame of the LMS window that exposes the API Adapter as a Document Object Model Object • Provide the API Adapter Chris Poole: Senior Content Developer

  9. The SCO must • Find the API Adapter • recursively search the parent and/or opener window hierarchy • Once the API Adapter has been found the SCO may initiate communication with the LMS Chris Poole: Senior Content Developer

  10. Assets • The SCORM launch model only requires that an LMS launch the Asset using the HTTP protocol • Since an Asset does not need to communicate with the LMS there is no need for an Asset to search for the API Adapter Chris Poole: Senior Content Developer

  11. Application Program Interface (API) • Communicates the state of the learning object to the LMS • Initialised • Finished • In Error Chris Poole: Senior Content Developer

  12. Why use an API? • Fulfills many of the SCORM’s high-level requirements for interoperability and reuse • It provides a standardised way for SCOs to communicate with LMSs • Shields the particular communication implementation from the content developer Chris Poole: Senior Content Developer

  13. What is it? • A set of predefined functions that the SCO can rely on being available • A piece of functional software that implements and exposes the functions of the API Chris Poole: Senior Content Developer

  14. Why Use it? • An API hides implementation details from SCOs • promotes reuse and interoperability • Gives content developers a common public interface to any LMS Chris Poole: Senior Content Developer

  15. The API is • a communication mechanism that allows the SCO to communicate with the LMS • Once the SCO is launched it can • “get” information from an LMS or • “set” information within an LMS • All communication is initiated by the SCO • No supported mechanism for LMSs to initiate calls to functions implemented by a SCO Chris Poole: Senior Content Developer

  16. The API Adapter object has three functions • Execution State • State Management • Data Transfer Chris Poole: Senior Content Developer

  17. Execution State • API has two functions to handle execution state • LMSInitialize(“”) • LMSFinish(“”), Chris Poole: Senior Content Developer

  18. State Management • The API has three functions that are used to handle errors • LMSGetLastError() • LMSGetErrorString(errornumber) • LMSGetDiagnostic(parameter). Chris Poole: Senior Content Developer

  19. Data Transfer • The remaining API functions transfer data to and from an LMS • LMSGetValue(data model element) • LMSSetValue(data model elementvalue) • LMSCommit("") Chris Poole: Senior Content Developer

  20. State Management • The API has three functions that are used to handle errors • LMSGetLastError() • LMSGetErrorString(errornumber) • LMSGetDiagnostic(parameter). Chris Poole: Senior Content Developer

  21. The API can be in on of three states • Not Initialised • Initialised • Finished Chris Poole: Senior Content Developer

  22. A SCO can behave differently in each of these states • Not Initialised • A SCO must • find the API • Call LMSInitialize(“”) Chris Poole: Senior Content Developer

  23. Initialised • A SCO can • LMSGetValue • LMSSetValue • LMSGetLastError • LMSGetErrorString • LMSGetDiagnostic • LMSCommit • LMSFinish Chris Poole: Senior Content Developer

  24. Finished • The SCO can • LMSGetLastError() • LMSGetErrorString() • LMSGetDiagnostic() Chris Poole: Senior Content Developer

  25. API General Rules • The function names are all case sensitive, and must always be expressed exactly as shown • The function parameters or arguments are case sensitive. All parameters are lower case. • Each call to an API function, other than the error handling functions, resets the error code. Chris Poole: Senior Content Developer

  26. The Data Model • A defined set of information that can be communicated. What the SCO and LMS should know. • LMS must maintain the state of the data elements across sessions. • Learning content must only use the predefined data elements. Chris Poole: Senior Content Developer

  27. So which Data Model do we use? • There are a number of data models under development in various communities and standards organisations • These draft data model specifications attempt to functionally group information sets to be exchanged between SCOs and LMS environments Chris Poole: Senior Content Developer

  28. Examples include: • student profile information • question and test interactions • state information • assessment • These draft data model sets are still under development and have not been widely implemented or tested Chris Poole: Senior Content Developer

  29. The SCORM Run-Time Environment Data Model • derived directly from the AICC CMI Data Model described in the AICC CMI Guidelines for Interoperability4 Chris Poole: Senior Content Developer

  30. It is expected that • In the future new data model sets will be adopted and incorporated into the SCORM • the data model elements defined in this version of the SCORM will map to new data model sets Chris Poole: Senior Content Developer

  31. To identify the data model in use • Names of the elements start with “cmi” • This signals implementers that these elements are part of the AICC CMI Data Model • Alternative data models, as developed, will start with a different designation • (e.g., adl.elementName instead of cmi.elementName) Chris Poole: Senior Content Developer

  32. The AICC and IEEE decided to reduce the number of elements in the AICC CMI Data Model • to ease the transition to new data models under development • many of the elements removed had not actually been implemented by most implementers • A list of elements removed from the AICC CMI Data Model that appeared in the SCORM Version 1.0 are summarized in Appendix C • The SCORM Run-Time Environment Data Model matches the reduced AICC CMI Data Model set. Chris Poole: Senior Content Developer

  33. The SCORM Run-Time Environment Data Model General Rules • The first symbol in the data element name identifies the data model. For example, "cmi" indicates the AICC CMI Data Model. This expands the functionality of the API by allowing the same API to be used with other data models; Chris Poole: Senior Content Developer

  34. There are three reserved keywords. These are all lower case and proceeded by an underscore • _version: keyword used to determine the version of the data model supported by the LMS • _children: keyword used to determine which data model elements are supported by the LMS • _count: keyword used to determine the number of elements currently in a list Chris Poole: Senior Content Developer

  35. All arrays are 0 based arrays • Items should be placed in the arrays in a sequential manner • The data model names are case sensitive • The data model is implemented on a SCO by SCO basis • One SCO cannot access another SCO’s data elements Chris Poole: Senior Content Developer

  36. Dreamweaver Course Builder Interactions • Claim to be AICC compliant • Objects do try to connect to tracking system • Objects do use cmi data model elements • Objects do provide good interactive functionality BUT • Elements are not referenced using the SCORM rules Chris Poole: Senior Content Developer

  37. Coding (how DW tracking works) G01.am('segm','Segment: Correctness_',1,0); G01.am('cond','Correct_01','G01.correct == true',0); G01.am('actn','Popup essage','MM_popupMsg(\'Correct\')',''); G01.am('end'); G01.am('cond','Incorrect_','G01.correct == (false)',0); G01.am('actn','Popup Message','MM_popupMsg(\'Incorrect\')',''); G01.am('end'); Chris Poole: Senior Content Developer

  38. Dreamweaver SCORM wrapper • Allows for the insertion of code to minimum SCORM conformance function mm_adlOnload() { if (mm_adl_API != null) { mm_adl_API.LMSInitialize(""); // set status mm_adl_API.LMSSetValue("cmi.core.lesson_status", "incomplete"); } } Chris Poole: Senior Content Developer

  39. Conclusions • Launch • Defines a common method for launching SCO’s and Assets • The API • shields developer from LMS implementation • Performs data transfer from SCO to LMS • Performs state management • The Data Model • Based on AICC cmi data model • Is designed to allow development and inclusion of new data models Chris Poole: Senior Content Developer

  40. Further Research / Development Work • Understand AICC cmi data model elements and how they can be used • Develop range of templates for • SCO’s • Assets • A range of interactions • That use the cmi data model elements in the SCORM format Chris Poole: Senior Content Developer

More Related