Tuesday, August 29, 2006
SCO fetcher
Warwick Bailey of Icodeon Ltd from United Kingdom sent me an email today asking me to comment on one implementation issue of my SCO fetcher solution for overcoming the cross-domain issue when delivering content within a SCORM environment. [see my other papers on SCORM here.]
In particular, it is related to the linked javascript files. In Warwick's solution, after fetching the SCO, the LMS will parse the incoming HTML and add a BASE tag to the SCO. By doing this, all referenced images, CSS (as long as their paths were relatively) will be displayed correctly in the client. However, linked javascripts, originating from a different domain will NOT be able to interact with javascript from the LMS domain. This is a browser implemented SECURITY and should NOT be broken.
Here is a minor details - albeit a very important one in the SCO-fetcher solution.
The original model is based on using multiple content management systems at the same time. ALL assets are stored in some CMS and we allowed multiple CMS support for a single SCO. That is, a SCO will consist of its base HTML (say stored in CMS-1), plus other assets such as images, CSS, animations etc sources from other CMSes (say CMS-2, ... CMS-n). Hence, we implemented absolute referencing to the resources.
As SCO, it is necessary to have javascript (at a minimum, javascript is needed to establish the connection to the LMS). In the original implementatin, all javascripts were embedded within the SCO and hence post no cross-domain scripting violation.
In Warwick's situation, if the javascript is linked in, the BASE tag will point the javascript to its original domain and hence the browser will block any communication of the loaded javascript with the javascript from the LMS.
As far as I can remember, the SCORM specification does not specify how the SCO should implement the javascript (whether embedded or linked) and I understand it is much easier to use a linked solution.
A little intelligence can easily overcome the problem - but is NOT the best solution. In Warwick's case, since the LMS is parsing the incoming HTML anyway, it is just a matter of locating the javascripts, fetching them and sending the javascript from the LMS domain (or embedding the javascript into the SCO).
A better solution would be to extend the SCORM specification slightly, including the two scenarios (embedded and linked javascripts) to describe a unified way of handling the situation. As an extra, this work will also open up the opportunity of defining a mechanism for overcoming the Mosaic Effect of Multi-use SCOs. [I am aware of other works in customising the look and feel of SCO, but I still believe my solution is a better fit to the development workflow of current SCORM content development efforts.]
I am in the private sector and have a family to feed. That means I cannot put public good before my responsibility of provding for my family. :-) I am happy to put in the effort to do this work if someone can sponsor my time and any associated costs.
cross-posted to Random Walk in Learning ¶ 12:00 pm
Warwick Bailey of Icodeon Ltd from United Kingdom sent me an email today asking me to comment on one implementation issue of my SCO fetcher solution for overcoming the cross-domain issue when delivering content within a SCORM environment. [see my other papers on SCORM here.]
In particular, it is related to the linked javascript files. In Warwick's solution, after fetching the SCO, the LMS will parse the incoming HTML and add a BASE tag to the SCO. By doing this, all referenced images, CSS (as long as their paths were relatively) will be displayed correctly in the client. However, linked javascripts, originating from a different domain will NOT be able to interact with javascript from the LMS domain. This is a browser implemented SECURITY and should NOT be broken.
Here is a minor details - albeit a very important one in the SCO-fetcher solution.
The original model is based on using multiple content management systems at the same time. ALL assets are stored in some CMS and we allowed multiple CMS support for a single SCO. That is, a SCO will consist of its base HTML (say stored in CMS-1), plus other assets such as images, CSS, animations etc sources from other CMSes (say CMS-2, ... CMS-n). Hence, we implemented absolute referencing to the resources.
As SCO, it is necessary to have javascript (at a minimum, javascript is needed to establish the connection to the LMS). In the original implementatin, all javascripts were embedded within the SCO and hence post no cross-domain scripting violation.
In Warwick's situation, if the javascript is linked in, the BASE tag will point the javascript to its original domain and hence the browser will block any communication of the loaded javascript with the javascript from the LMS.
As far as I can remember, the SCORM specification does not specify how the SCO should implement the javascript (whether embedded or linked) and I understand it is much easier to use a linked solution.
A little intelligence can easily overcome the problem - but is NOT the best solution. In Warwick's case, since the LMS is parsing the incoming HTML anyway, it is just a matter of locating the javascripts, fetching them and sending the javascript from the LMS domain (or embedding the javascript into the SCO).
A better solution would be to extend the SCORM specification slightly, including the two scenarios (embedded and linked javascripts) to describe a unified way of handling the situation. As an extra, this work will also open up the opportunity of defining a mechanism for overcoming the Mosaic Effect of Multi-use SCOs. [I am aware of other works in customising the look and feel of SCO, but I still believe my solution is a better fit to the development workflow of current SCORM content development efforts.]
I am in the private sector and have a family to feed. That means I cannot put public good before my responsibility of provding for my family. :-) I am happy to put in the effort to do this work if someone can sponsor my time and any associated costs.
cross-posted to Random Walk in Learning ¶ 12:00 pm
