Tyde’s slides entitled CMI Working Group, June 2000 are available for review at http://ltsc.ieee.org/meeting/200006/doc/cmi--20000626.ppt.
Tyde reported on WWW9, in which Microsoft & IBM declared official backing of SOAP. SOAP is attractive to LTSC because it is designed to be an XML “messaging model”. SOAP can be bound to HTTP and is a possible solution to the CMI HACP/internationalization problem. Tyde suggested that the SOAP approach is more generic and more easily adapted for international differences.
SOAP is a one-way messaging model, and all other interface issues are built on top of the SOAP level. Dan and Tyde are continuing to track the developments in this area.
Tyde reported that the ADL Plugfest also included a ADL SCORM WG meeting to discuss the API. The Plugfest was a weeklong series of conformance tests. The Plugfest participants did agree that “version 1.1” will be completed very soon. Small issues were brought to light with SCORM interpretation, such as when nulls are equivalent to an empty string (LMSInitialize). It was agreed that all parameters will return strictly strings, so then nulls must be represented by empty strings. In addition, some people requested that LMSFinish return a Boolean success value, and this suggestion was adopted.
Frank complained that the SCORM WG meeting was not an open meeting. Tyde agreed that this was not right, and he and Dan hope to take steps to correct this policy. Tyde also pointed out that the parts of the SCORM that were being addressed in the meeting were sections that are AICC-originated and being standardized in CMI, but the IEEE was not invited.
The SCORM WG also agreed to begin work on Version 1.2 that will use the same approach as 1.1, but will address more substantive issues. Version 1.2 should be completed sometime in the Fall. Note: these are versions of ADL’s SCORM, not the IEEE CMI documents.
Version 2.0 of SCORM will hopefully be reached in 6-12 months. This version will be open for complete re-architecting of the system. The SCORM WG hopes to include capabilities that some feel are essential like navigation rules, support for graphical skins, support for many small data models, and better integration with other specifications. This redesign will allow modular data models, so that you can use multiple data models alongside the CMI data model (like QTI).
The goals for the LTSC are described as follows:
Frank made note that the dates of the LTSC September meeting have already been set, and there is one overlapping day with the AICC meeting. The easiest way to handle the need to hold the additional meetings is to extend the WG time. Dan added that this change would need to be posted as soon as possible. Brandon and Claude brought up the fact that there are other conflicting conferences. Frank then suggested that CMI may want to schedule a special meeting to accomplish these goals as has been done in the past.
Tyde continued to report that there were 14 LMS venders and 18 content vendors participating at the Plugfest. Participants were beta testing SCORM conformance with the API, CSF in XML, and IMS metadata. The tests were quite successful and the software will be released soon. The next Plugfest is scheduled for August, 2000, at which time they would like to change to more of an academic focus but with a “conformance track”.
Tyde then asked Kiyoshi Nakabayashi of NTT-X to report on CMI developments in Japan.
You may view Kiyoshi’s slides entitled Introduction to Japanese Activities on CMI Specification at http://ltsc.ieee.org/meeting/200006/doc/ltsc0006.ppt.
Kiyoshi reported that the Advanced Learning Infrastructure Consortium was established in April 2000. The Japanese government supports this consortium through the Ministries of Industry, Education, Labor, and Telecommunication. Within the consortium, there are 3 subcommittees: Interoperability, advanced technology, and demonstration. CMI activities in Japan include the development of an interoperability experiment based on the CMI API. Through this work, they are developing an Offline Content Specification, a Content Package Licensing Specification, and they are working on full integration of streaming media applications.
Within the API Module development, they have developed a CBT Interface module and used a CMI server. There is an import/export module which handles both AICC CSC course file and the SCORM CSF file. There is a DOM-like API to manipulate CSF elements (insert, remove, parent, prevSibling, nextSibling. The Communication Module is the counterpart of the API adapter on the CB side. It provides content launch and communication API for the CMI. The SCORM-based content format uses API module for offline learning environment. In Japan the Internet connection costs are still very expensive. They are using the API module for offline learning environment and download/upload protocol.
Content Package Licensing is based on the IMS Content Packaging Specification that allows the content to embed an encrypted license to the users through the WBT server. They have also integrated streaming media with CMI content mapping and media control including a learner operation log.
Their API module development is still in the design stage. The interoperability experiment takes place this fall with several vendors involved. There are several internationalization issues that need to be considered. Through this development process, the consortia have identified many issues with the character codes for the Japanese language.
Frank answered that this specific issue has been addressed within PAPI, and he recommended that the CMI WG adopt the same solution because the PAPI solution has been tested for 10 years.
Kevin then took the floor to present the Gotham API that Fretwell-Downing has developed for use with CMI. You may view Kevin’s document at http://ltsc.ieee.org/meeting/200006/doc/figures.doc.
For all of the good work that has been done in the CMI, Kevin’s organization has been following the API development in hopes that it could be used for some of their work in the UK. They have discovered that you can run multiple data models within the API, and since they had already done this with the QTI, they decided to develop their own API with this functionality. In this discussion, Kevin is pleased to say that the IMS has adopted his content API. There are some organizations that are trying to extend this API for synchronous communications. There are some people looking at the general issue of database synchronization between systems. Fretwell-Downing is committed to making sure their API remains compatible with the SCORM implementation. They are committed to using Javascript (Kevin’s group has implemented the interface in Javascript and then below that in VisualBasic). Kevin’s organization has established a principle of applying different data models. They are now defining new data models that can be used over the API, and they have added discrete functions with respect to the LMS and user interaction within the content. The models that they have identified so far would enable the addition of new features including bookmarks & annotations, personalization, assessment, learner modeling/styles, simulation, navigation, activity audit. Kevin’s group also has a keen interest in SOAP. They hope to forward the Gotham API specification to the IMS group. They have a mechanism for describing content, as well as a mechanism for importing content into a LMS.
He has planned for API support of third party services like streaming media servers, examination bodies, and adaptive content/simulations. They recognize the fact that the adaptive content servers are most likely not going to be standardized, so the API must allow for external communications with these services. They are considering a call-out function that uses the data model and receives information to be delivered back to the LMS.
Kevin turned over the floor to Claude, who presented his ideas about Control Play Rules for content. You may view Claude’s white paper at http://ltsc.ieee.org/meeting/200006/doc/control_play_rules.doc
These are rules that apply when a content tree is “played” in a runtime system. It is actually an abstraction of actual implementations that may vary from system to system. Categories of rules include security, visibility, navigation, presentation, evaluation & tracking, aggregation, and editing.
The content does not do sequencing. Ideally this information would be stored externally in the course structure format.
The rules can be combined in style sheets and are inherited from the parent node. Rule inheritance can be turned off and can be locally overridden. Security rules are special (limits on override), and rules are typically used to determine how to set up the context of execution and to determine how to handle a runtime event. There is a set of predefined events.
Whenever a node needs to be run, the rules determine the method of execution for that mode, the presentation, adaptation to delivery system, etc.
Tyde asked Claude how easily these rules interact with the API, and Claude explained that it is just plugged in with additional Javascript. Claude pointed out there is not an AICC pre-defined event. Bill Melton asked how well it fit with the SCORM. Claude explained that it fits very well because right now the SCORM has a lack of sequencing information and this would allow you to put the intelligence back in. Branching behavior might be possible if we could create a flow-chart type map for navigation within one node.
Claude encouraged the LTSC to review his draft white paper and discuss it on the reflector or provide feedback to him directly.
The floor was then turned over to Dan Rehak who discussed his technical vision of the API. He presented part of the presentation given at the ADL meeting. Dan used various slides from CMUOnline at: http://online.web.cmu.edu/public/information/technical/88m10062100/index.html including a Course Model at: http://online.web.cmu.edu/public/information/technical/coursemodel/index.html
Reusable content assets and repositories require a consistency of the metadata catalogs. You can never have too many content resources and metadata cataloging and consistency will be critical. In the experience gained at CMU, Dan recommended that the Metadata should only describe what the content IS, not how the content can be used. Do not build rendering and display assumptions into content assets. Course sequence or learner behavior should not be included in learning assets. Do not build launch information into the repository content – someone may want to reuse your content in a different manner with different sequencing, and presentation! The course objects should be separate from the course structure, which should not imply flow sequence or control of launching events. Do not design pedagogy into course objects.
In their SCORM experience, LMS can output SCORM CSF and AUs for any sub course or AU in the repository. There is a growing consensus that the content should not have control, which is the current model of CMI. CMI is a restrictive model relative to what CMU Online has done. CMU Online has a policy based rules system. The CMU Online course model element consists of structure, objectives, rendering, and rules that point to the course element metadata. Their opinion of SCORM 1.x API is that it is problematic and insecure. The API employs a terrible intermixing of attributes and does not represent flow or sequencing. It is obvious SCORM will be incorporating IMS QTI and Packaging. Unfortunately, CMU says QTI falls apart when used in a rules-based environment. Similarly, QTI seems to bundle behavior assumptions in the wrong way. Course structures need a different model, and they recommend that instead of using the API they would like to use something like SOAP.
In CMUOnline, “everything is a node.” The kinds of nodes they have are metadata nodes, resource nodes, people nodes, course nodes, content nodes, model nodes, system kernel state nodes, student state, learner state, and system state. The course model is a structure of arbitrarily connected nodes (ugly trees).
When referencing an object, we should be able to conceive an XML namespace description to access the nodes. Their processor will not fire a node until the preconditions are satisfied for that node. If the data models were consistent, then we should be able to access the metadata for a node in real-time while the learning asset is being executed.
CMU uses packaging, metadata, CSF structure model, competencies, and have created new data models for control, display profiles, and assessments.
Tyde regained control of the floor to continue discussion of LTSC’s goals for CMI.
Frank offered to help Tyde with administrative tasks for an extra or extended CMI meeting in September. Tyde felt this option should be discussed with Jack and perhaps be posted on the reflector.
Kevin asked if this meeting would involve the current version of the API. Tyde explained that there is considerable interest in progressing to the newer version of the API. The goals of the AICC and the goals of the IEEE are not entirely congruent when it comes to the entire specification. The AICC’s mandate was to bring this document to the IEEE and make it a standard. There are implementers that are running on the current work, and others that think improvements could be made with a relatively small amount of work. Tyde would like to evaluate the ramifications on content packaging, QTI, as well as the CMI specifications.
Frank commented that this document has been in work for 3 years and is over 300 pages, and he would like to see the document be completed and sent off as a standard. Tyde would like to see some parts of the document removed.
Dan added that the LTSC needs to decide if as a WG we are going to constrain and “freeze” an AICC-CMI model in full recognition that most of us think it is the completely wrong thing to do. The other option is to kill the work completely, and restart a project from the right perspective. If we have to restart, Dan feels we need to go to someone who knows what we want to do.
Claude points out that every change to the API is currently rippling all the way back to the file-based specification. We really need to have a clear division. Tyde suggested that we need a migration path that shows some compatibility with what is already defined. Frank answered that we would need to start with getting consensus on the deprecated use of the existing specification and on features that will be withdrawn.