Last week, we had another meeting of the ADL Technical Working Group to discuss current issues with SCORM 2004, plans for SCORM 2004 3rd Edition and future directions for ADL. I’ll spare you all the detailed SCORM minutia that we talked about, but below are some of the highlights of the meeting that may be of interest. Note, none of these statements should be considered official statements or positions from ADL, this is just what we talked about.
- Started with SCORM 2004 3rd Edition, ADL will be using a new versioning scheme for the SCORM books. This change is designed to reduce the confusion that results from the detailed book version number and the actual version and edition of SCORM. All the books currently have a version number on them like 1.3.2. This version number is the detailed internal number used to track editorial changes to the text, they are not meant to signify any changes to SCORM. In the future, this detailed version number will be de-emphasized and changed to begin with version 1.0 for each edition. So now, instead of SCORM 2004 2nd Edition, book version 1.3.2, we will have SCORM 2004 3rd Edition (editorial version 1.0).
- One of the topics big on ADL’s to-do list has been that of stewardship. ADL has done a great job creating the SCORM standard, but they are now looking to the future to figure out who will maintain it going forward. Since SCORM has been adopted all over the world, a leading candidate is ISO. SCORM was recently submitted to ISO for general review. Note, it has not been submitted for standardization yet, simply for comment. This represents a small first step toward handing custody of SCORM over to an international body.
- DoDI 1322.nn is now “really close, really”. This instruction from the Department of Defense will mandate that all DoD online training be SCORM conformant and registered in the ADL Registry (an instance of CORDRA). The instruction has been “really close” to signature for quite some time now. Apparently now, it “really is really close”.
- There have been some problems with SCORM 2004 certified LMS’s not being interoperable with SCORM 2004 certified content. These incompatibilities mostly result from the fact that the SCORM 2004 sequencing specification is quite complicated and frankly, hard to implement. Furthermore, its complexity makes it inherently difficult for ADL to test every possible behavior. The result is that some LMS’s are being “coded to the test”….they will pass the Test Suite, but fail on a lot of other behaviors. ADL acknowledges this problem and we spent a significant amount of time at the TWG meeting trying to figure out the best way around it. One conclusion we came to is that more tests are needed. Some of these will be added, but we will never be able to test all circumstances. Another conclusion is that we need to start testing some of the more common sense type behaviors that were previously left up to the implementer. That means, ADL is going to start testing for some basic usability and for sensible behavior when exception conditions are encountered. It is a rather large project to properly define this testing, but it was agreed that it is an important enough problem to delay the release of SCORM 2004 3rd Edition to at least get the low hanging fruit.
- Perhaps the most controversial discussion centered around the use (or non-use) of SCORM metadata. ADL proposed a change to the metadata profiles that would add 5 required metadata elements for Content Aggregations (manifests) and remove all the requirements for other metadata profiles. Some argued that nothing should be required anywhere (reason being that if you require it, people will have to enter it). Others argued that more should be required (reason being that if you place requirements for fields people don’t care about, they will just be filled with junk, or there will be no metadata at all). What are your thoughts? Anybody have any passionate ideas about proper metadata requirements?
- There seems to be a lot of interest among the content developers for incorporating the SSP specification into SCORM. SSP (shareable state persistence, from IMS) basically allows you to save large buckets of state data that can then be shared across SCOs and it is very useful for developing simulations. It looks like SSP will probably be a near-term effort for ADL, but they are hesitant to do more with it until the industry has more experience with it. Let us know if you have any use for SSP or if you know of any existing implementations.
