ATutor

Learning Management Tools


  1. Home



Pages:1 2 3 4 5 6 7 8 9 10 11 12 13 14 15


SCORM compliance



  • 2004-10-14 16:42:22

    SCORM compliance

    I'm not shure if this should be posted to the support or to the community forums.

    I want to know what SCORM version does ATutor conform to and to what level it conforms.

    thanks.


  • 2004-10-14 18:14:33

    SCORM CAM 1.2

    It conforms with SCORM Content Aggregation1.2, and IMS Content Packaging 1.1.2. This information can be found in the imsmanifest.xml found in a content package.

    There is some talk about extending ATutor conformance when then next SCORM specification is released. There are some issues with the current spec that prevent us from adopting the full specification.


  • 2004-10-15 14:30:07

    Thanks

    Thanks for answering so quickly. I'm actually evaluating ATutor because I'm involved in a project to build an (other) open source LMS. We'll try not to reinvent the weel and inovate - the project is still on it's early days.
    Anyway, I'm very curious about the problems you faced implementing SCORM 1.2 compliance, why the choice not to implement RTE and what are the difficulties with the 2004 spec. If you could point me to documents, forum or mailing list discussions it would be excelent. Thanks again.


  • 2004-10-15 18:22:42

    Three Problems with SCORM

    First, everything we develop at our centre is required to conform with accessibility specifications (WCAG), so people with disabilities are able to participate equally in all learning activities. One of the accessibility rules is that if client side scripting is used (namely Javascript), it must also function effectively without scripting. Because SCORM SCOs rely on scripting and will not function otherwise, they fail this rule.

    Second, from both accessibility and engineering perspectives, content, presentation, and controls need to be separated. In SCO's the javascript navigation controls are not separable from the content in which they are embedded, thus limiting how an LMS might choose to display navigation elements.

    Third, because I am required to use Javascript to present SCO controls, I am limited as a developer in how I can choose to implement the SCORM specification. The SCORM specification has become technology dependent. This should not be.

    We have a better way to implement SCORM to meet our accessibility requirements, but we can not implement it and be compatible with current SCOs. We can make current SCO's work, but they would not be fully accessible. We're suggesting moving all the sequencing rules, currently contained in the embedded scripting, into an xml file and letting the LMS decide how to present to navigation elements, whether through Javascript or through some other means.

    What we would like to propose is the eventual removal of the embedded javascript buttons in favour of an XML based strategy for defining sequencing rules in SCOs. There is much resistance to this from SCORM folk. It would be a major shift in the specification that would effectively make all current SCOs obsolete. They would be right to say that such a proposal would unlikely be adopted. Over the long term however, shifting from a specification that requires client side scripting, to one that can support client side and server side methods simultaneously, would make the specification more robust, and more compatible with accessibility specifications.

    It's a longer story than that, but you get the idea...


  • 2004-10-15 18:50:15

    followup on Community Discussions

    Continue this discussion in the Community Dicussions forum:

    http://www.atutor.ca/view/16/2779/1.html