The problem SCO described in Step 52 is now working correctly, so why do I need to look any further? There’s a more subtle problem.
The ‘datamodel.element._children’ mechanism described in the SCORM RTE specification seems to have been developed so that there’s a way for a SCO to determine which data elements are supported.
For example, if the SCO was to do this:
var supported = LMSGetValue('cmi.core._children');
the variable ‘supported’ would be set to ‘student_id,student_name,lesson_location,credit,lesson_status,entry,score,total_time,exit,session_time’ which is a list of the data elements in the cmi.core group that the LMS supports. This allows a SCO to determine whether or not it can use a particular data element before it tries to do so. And this is all well and good except …
… it doesn’t cover all of the optional data elements. The data element that the problem SCO was trying to use – cmi.comments – is not part of the cmi.core group of data elements, so looking at the value of cmi.core._children wouldn’t have helped. In fact, cmi.comments isn’t part of any group at all.
Now, the SCORM 1.2 RTE says that:
- If an element IS supported but contains no child elements, an empty string is returned.
- If an element IS NOT supported, an empty string is returned.
So there would be no way to use ‘_children’ to determine if cmi.comments was supported since:
var supported = LMSGetValue('cmi.comments._children');
would always return an empty string. Instead, according to the specification, one has to look at the error codes:
So, if I execute the following:
var supported = LMSGetValue('cmi.comments._children'); var lasterror = LMSGetLastError();
then variable ‘lasterror’ is set to 401, and I know that the cmi.comments element is NOT supported.
OK – it seems pretty odd to me that a system would be designed to cover some, but not all, of the optional data elements. But there it is – we’re going to have to live with it.
And it highlights a more fundamental issue that I need to fix – I’ve been very lax with my handling of the error codes so far – that has to change!
Pingback: Step 60 – Supported Data Elements | VSSCORM
Mark and Mike,I’ve got to say that I agree that SCORM the fact that there are still little gahctos all the time with loading and running SCORM courses under SCORM compliant LMS products is a bit of a surprise. My guess is that most people creating content (like 95%+) don’t care about things like sequencing, etc. They likely are building a course with a single SCO.In these cases, there shouldn’t be any question about how to report scores back and how the LMS and/or course decides whether the course is considered complete, etc. There are a few semantics that always seem to cause the gahctos.So, while defining the SCORM CORE in SCORM 2.0 is a good idea, I think all of us would welcome a more definitive, probably tightened definition of SCORM compliance for courses and LMSes that would avoid the issues for these 95%+ simple cases.