OK – I’ve come quite a long way with understanding the SCORM 1.2 standard (although it would be wrong to claim that I understand all of its nuances), and a fair way with the development of the VSSCORM interface. So, this is a short post to talk about where I think I’m going next with the VSSCORM project, and to ask for your feedback.
There are basically 2 areas that I believe need to be addressed to make the VSSCORM 1.2 RTE code more robust and reliable.
- Error Handling
I thought, at first, that well-behaved SCOs wouldn’t trigger any error codes so I haven’t spent much time on this aspect of the code. But that’s not always true – I’ll talk about an example in an upcoming post where a SCO uses the error code to see if an optional data element has been implemented or not before trying to write to it. So I think I need to take some time to implement error handling as specified by the SCORM 1.2 RTE specification.
- Optional Data Elements
The first version of the RTE implemented only the mandatory data elements, and this seems to be good enough for many (most?) SCOs. But I’ve been coming across some SCOs that require the use of optional elements. So I think I should implement them when I can.
Then there’s the VSSCORM Manifest File Reader. It seems to be working pretty well, but I think the best way to make sure would be to build it into a “mini-LMS” which would allow a user to:
- Upload a SCORM content package (including multiple-SCO packages)
- Choose and run a SCO using the VSSCORM RTE
I could also use this as a test harness by implementing some simple tools to look at the state of the database and the API cache as well as monitoring/logging the API calls for debugging purposes.
So that’s what I’m thinking. However, if you have any personal opinions on where I should be taking the project, please let me know!
Next time – some interesting problems raised by a reader’s SCO.