I’m going to start simple by reading the resource information from the manifest file. To do this, I’m going to use the DOM extension to PHP that’s part of the core of PHP5. This will allows me to parse and read the manifest XML data. You can find the documentation for the DOM extension [here].
The CAM specification has a long and detailed description of all the possible and required XML tags. But it’s far easier to see what’s actually going on if we take a look at a real example and break it down into its component parts. Note that I’m going to assume you have a basic working knowledge of XML.
I’m going to look at a typical manifest file from one of the test courses that I’ve been using to see if I can identify the key elements. If you want to follow along, I suggest that you open [this link] in your browser.
Last time, I looked at the Meta-Data section of the SCORM 1.2 CAM specification and decided to ignore it (for now, at least). In this post, I’m going to start to look at the Content Packaging section of the CAM specification. This defines:
It’s been a while since my last post, and this one will be very short. And here’s why …
I’ve been working through the second part of the SCORM 1.2 Content Aggregation Model (CAM) specification which deals with Meta-Data (data about data). This part takes up over half (by weight) of the document, and seems to relate entirely to information that the content developer can choose to include (or not), and the LMS developer can choose to read (or not). But none of it seems to relate to my immediate target – developing a simple way to load and run a SCORM 1.2 package. And none of it, as far as I can see, is mandatory.
So, for now, I’ll ignore it and move on to the section on Content Packaging which promises to be much more relevant to this project. Perhaps I’ll revisit Meta-Data later?
I’ve had a bit of a break since I released VS SCORM 1.2 RTE Rev 1.0. But now it’s time to get back to the task in hand. At this time, I should be able to run any SCORM 1.2 SCO (‘Shareable Content Object’ in case you’d forgotten) that’s been installed in my ‘imaginary’ LMS.
Now it’s time to shift attention to another part of the SCORM specification – the Content Aggregation Model or ‘CAM’ for short. You can download a copy from the ADL website, or from [here].
At this time, I’m going to pause development of the VS SCORM 1.2 Run-Time Environment (RTE) since my implementation seems to work well enough for my purposes, and tidy it up for formal release as Rev 1.0.
As I noted in a previous post, I’ve made some significant changes to the code structure in order to move all database- and LMS-specific code to one place (the subs.php file), and to support multiple students/multiple SCOs.
In my last post, I looked at the changes that I needed to make to the “scormvars” database table, and to the database-specific functions in the subs.php file to support the SCOInstanceID.
Now, I have to figure out how to get the value of the SCOInstanceID from the LMS which initiates the session, through the client-side JavaScript API code, to the server-side PHP API code and then to the subs.php file. In other words:
I’m going to start working from the bottom of my new code structure upwards starting with the database and the subs.php file (bear with me … this does make sense!).
I’ll start by modifying the table structure for the “scormvars” table in the database by introducing a column for the SCOInstanceID variable. I’ve also taken the opportunity to index the table on SCOInstanceID and varName to make the code run a little faster.
A student can access multiple SCOs, and a SCO can be accessed by multiple students. So I start with a many-to-many relationship like this.
How I get data from the LMS to initialize the SCO session is going to depend on the way that the LMS is coded. So it’s not possible to write this in a completely generic way. Instead, I’m going to take some time to re-structure the code to move all LMS-specific and database-specific code to one place. This should make it considerably easier to work with.
