This blog post is my attempt at documenting my portion of the session. Bear in mind that there was a lot of Q&A from the audience, and much of the session was ad-libbed. The descriptive text presented below may not exactly match was what in the session, but the gist is there.
If you’re interested in the nitty-gritty technical details, check out the Developer’s Guide on the LETSI website.
Some quick background information on the LETSI organization.
LETSI stands for “Learning Education Training Systems Interoperability”.
LETSI believes in pushing training systems forward through agile, iterative software development. Make things quickly, get feedback, and make changes. In our current Internet age, we don’t have the time to take years developing a spec. Make something that works, then turn it into a spec.
LETSI believes in engagement with standards bodies and vendors throughout the process. If a new technology is to become mainstream, it’s vital to get vendors in on the action. Make them stakeholders and get them involved in the project at an early stage.
Unlike some standards bodies, LETSI is transparent and open — there are no strings attached. Membership is not limited to corporations or agencies. Want to have a say in the future of training technology? Join LETSI and you could be on the conference call next week.
The current SCORM architecture requires that courses be launched in a frameset or pop-up window.
The LMS website typically performs data gets/sets on a database using a combination of ajax (xmlhttprequest) and server-side scripting (PHP, ASP, Java, etc.).
The LETSI RTWS changes the architecture to eliminate the middleman (the LMS website), allowing the course to directly communicate with the LMS backend using SOAP. (SOAP can be loosely described as XML sent via HTTP requests.)
No dependence on the web browser also means the course content can be hosted anywhere, and is no longer required to be stored in the LMS system.
Note: In some prototypes, the course must be launched from the LMS for the first attempt. This is due to registration requirements that are still being ironed out.
The accessibility benefits of the LETSI RTWS are debatable, but here are some of my personal beliefs about how the RTWS can make a course more accessible:
2. No reliance on web browsers means a course can be built in a desktop app or other environment that may (or may not) be more accessible than a web site or Flash movie. Of course, this is completely up to the developer, but the possibilities are there if the developer chooses to go down that path.
Under the LETSI RTWS, courses no longer need to be uploaded to the LMS and can be stored on ANY web server. There are several useful byproducts of this:
1. Course manifests no longer need to list every course asset. (Manifests are still required because they contain core data about the course, including the shared secret.)
2. If you’re a course vendor, you can maintain control of all of your course materials and simply provide a link and manifest to clients. No more ZIPs!
3. Since the course materials remain on your server and are not required to run on the LMS server, you’re free to use server-side code (previously a taboo in SCORM).
Despite their often negative reputations, LMSs provide a key service for your SCORM course: a SCORM API with error-checking (including error/debug messages) and behind-the-scenes handling of the CMI data model for you. The RTWS is not currently equipped to provide detailed error messages regarding the use of the CMI data model; if you choose to use the LETSI RTWS in place of the SCORM API, you will no longer have the benefit of the SCORM API’s error messages.
In the RTWS each ‘set’ request is an XML document created by your course and submitted to the server via HTTP. Since your course is creating and submitting the XML, it must use its own logic to determine if there are any errors, such as malformed XML or misuses of the CMI data model. For example, if your course accidentally tries to set a read-only field such as learner_name, you will not receive any error messages. It is up to your course to ensure the specifications of the CMI data model are being followed.
(Hopefully in the near future there will be 3rd-party libraries or frameworks that will provide this logic for you so you won’t have to write your own.)
Also, your course must be using a technology that supports SOAP.
The RTWS currently only supports single-SCO courses, and does not support SCORM 2004’s Sequencing and Navigation rules.
On a related note, since the content is being abstracted from the LMS, the LMS’s SCORM “player” will not be available to the RTWS course.
You can read more about the RTWS at http://letsi.org/rtws
Reminder: LETSI membership is open to the public. If you’d like help shape the RTWS (or other LETSI projects), join us!
Additional notes and tidbits not covered in my portion of the presentation
- I briefly demonstrated a prototype I created for Flash-based courses. My prototype uses a modified version of my pipwerks SCORM ActionScript wrapper, allowing developers to simply swap out the pipwerks SCORM class file with a new pipwerks LETSI RTWS class file and still have their course behave as it did with SCORM 2004. This prototype is not available to the public yet, but when I’ve worked out the bugs I will be sure to post a blog entry about it. Stay tuned!
- The LETSI RTWS is based on the SCORM 2004 (4th Edition) spec and uses the same CMI data model.
- Because the RTWS uses a new launch approach, support for querying the course’s attempt history has been added to the data model (see GetAttempt and GetAttemptList in the RTWS documentation).
- Unlike SCORM, a Get request in the RTWS returns the entire data set in an XML file. It’s up to the course to parse the XML and extract the value for a particular CMI element. I’ve whipped up a document mapping the CMI elements to their XML equivalents.
- A Set request can be partial (set a single or small group of elements) or complete (set the entire data model).
- SCORM’s Initialize() and Terminate() methods are not currently used in the RTWS.
- Rustici Software (scorm.com), Booz Allen Hamilton, and Meridian are all creating LMS prototypes that support the RTWS.
- Rustici Software hopes to fold support for the RTWS into its SCORM Cloud service once the RTWS is ready for prime-time.
- The ADL (owners of SCORM) are not involved with the RTWS, but they are aware of its existence and are monitoring the situation. In a separate action, the ADL is requesting input on the future of SCORM via Project Tin Can. It is LETSI’s hope that the RTWS, when ready, will be folded into the ADL’s plans for SCORM and that the two will co-exist peacefully.