Chen - Simplifying SCORM While Keeping it Feature Rich

The APIs we proposed have to be agreed upon on the interface level, a concept not much different from other technologies like COM and CORBA. For COM, interface is expressed in terms of a specialized language called IDL. Once IDL-based interfaces are defined (For example, IUnknown for generic query, IDirect3DDevice9 for 3D graphics, etc), it becomes straightforward to translate those interfaces into other languages like C++ or Java. In fact, most COM developers are not even aware of the existence of IDL: they just pick up the APIs of their language choice and start to use them. Other similar examples can be found in Web Services (WSDL) and .NET (CTS).

When you mentioned that "A standard, by definition, needs to dictate one way of doing things", I respectfully disagree. The success of those technologies can be largely contributed to their sensitivity to meet the needs of various stakeholders, who are often very interested in solving their domain problems with their familiar toolsets. In other words, forcing developers to use "universal" solutions (web service, JavaScript and a unified CMI model defined in a 20-plus page document) is often a distraction, not an incentive for adopting a technology, especially in a era when choices are abundant (e.g. Web 2.0). I personally believe that a more effective standard should focus more on conceptual contracts than on mechanics of the contracts.

As to JavaScript's performance, it is a real problem for simulation developers. Communication with the backend data store (not necessarily LMS system) in real-time is a major challenge I have to deal with daily. Simulation developers switch to Python and Lua not by accident.

Even though I agree that web service "could go a long way", web service itself is not the appropriate technology to realize SCORM's original goal of "provide access to the highest quality learning and performance aiding that can be tailored to individual needs, delivered cost effectively anytime and anywhere". What if there is no LMS or internet for the simulation training? What if somebody want to develop a training course that can truly be tailored to individual needs and deployed anytime and anywhere? Web service offers a good starting point, but it will not carry us to the end point.

As to the statement of "underlying CMI data model is intimidating": it is more based on my personal experience than on scientific research. In our past project, a team of four developers was involved to make our courses SCORM compliant, and we had little past experiences with SCORM. The initial learning curve was deeper than we thought: for example, what features are mandatory and what are optional? How to use cmi.interactions to capture simulation-related data when our data points are well above the limit of 250? How to pass data to the backend data storage when there is no LMS? How to deal with inconsistencies in the SCORM data standard itself as was described in the paper?

Some would argue that it is professional developers' responsibility to learn the complexity of SCORM (like CMI schema documentation) and figure out a way to address the implementation issues. That's what our project team did in the past six months. But eventually we came to realize that we prefer to write code with explicit contracts (type safe APIs) instead of generic contracts implied in the CMI data model. By dealing with an explicit contract limited in scope, the code becomes simpler, stable and portable. Instead of calling multiple setValue() functions to pass data for a single interaction, we can call one API function with all necessary parameters. If we pass the wrong type of parameters or miss one parameter, the compiler will tell us the error so we don't need to wait till runtime. Even if the underlining CMI data model changes overtime, we are still confident that our applications will work as long as we update the corresponding middleware. We like this alternative, and this is why we write this whitepaper to get your feedbacks. My personal experience with Boost convinces me that the "divide and conquer" approach could have its merits in the e-learning community who wants to address issues larger than web training and conventional LMS systems.

There is a Chinese saying, "throw a brick to attract jade". Six months of experience with SCORM is not a very impressive record, and our points are more likely to be brick than jade. But we will be content if new ideas worthy of jade would come out of this API discussion. Thanks!

Thanks Nina for your comments! I cannot agree with you more that there is a clear difference between technical specification and the tools! That's actually what we are trying to say in the paper, but I obviously didn't convey it very well

There is no doubt of the needs to develop more tools to hide SCORM's complexity. But if the single-API paradigm remains unchanged, developers will continue to deal with the complexity of communicating with a more feature-rich SCORM through a generic interface. Some will say that the code is easier to read if all communication is done through the traditional setValue() and getValue() functions. The problem is with the parameters in those function calls: how do you ensure that you are passing the correct parameters? When CMI data model changes, there is a big chance that the legacy code will be correct in syntax, but incorrect in logic. Instead of hiding the complexity of SCORM, we recommend to explicitly express those complexities through dedicated APIs. The benefits are more relevant APIs for domain developers, better syntax check and more stable codebase. "Divide-and-conquer" API design is not meant to remove all complexities inherent in any e-learning systems, but to manage them.

I understand your worries about too many APIs. But if there are two choices:

1.      Overhead of learning the APIs in your domain

2.      Overhead of learning the CMI model that covers all domains

What would you choose? I personally like option 1. It's hard for me to envision that LETSI could somehow figure out a CMI scheme that will cover most future e-learning scenarios (emerging technologies, new learning paradigms and new education contexts...) while keeping developers to write simple code. It is much more likely to devise multiple APIs, each designed to solve its particular problem. My past experience with this API design is with Boost, a C++ open source library which deals with problems ranging from calendar management, statistics to image processing! Since interactions between domains are reduced (there will be no all-encompassing CMI data schema document), the chance of writing more portable and reliable code will be higher.

From a standard perspective, we envision that APIs would become the technical specification for SCORM, so the CMI data model and many other details about SCORM will gradually become less relevant. LMS will not even be required for a SCORM system, since simulation or game applications might not be connected to a LMS system.

Thanks for your inputs!