Consolidation before the leap; IMS Enterprise 1.1
Consolidation before the leap; IMS Enterprise 1.1
Like most point releases, version 1.1 of the IMS Enterprise specification represents an important, but relatively unspectacular maturation of the 1.01 spec; more of a reality-check than new bells and whistles, and none the worse for that.
So should users of learning management systems (LMS) wait for the much more comprehensive version 2.0 that is due in the autumn? They could, but the rather more comprehensive revision envisaged in 2.0 may mean that version 1.1 will be relevant for some time to come. Also, a closer look at the changes since the 1.01 spec reveals a few useful improvements.
Some implementers of IMS Enterprise 1.0 and 1.01 compliant systems, for example, found that true interoperability requires a much tighter specification of the data that are transferred from one system to the next. The 1.1 specification is much more detailed and specific in that sense. Not only is the specification of the information model (the central set of data definitions) more than twice as long, there is now also a clear requirement on makers of LMSs to read and write valid data, as defined by the Enterprise XML schema. The implementation guide is also much more detailed. All of this should mean that exchanging data between different version 1.1 compliant systems should require less tweaking and checking.
Less easy to address is the issue of the identifiers of IMS Enterprise objects; the basic units of data that should flow between IMS Enterprise compliant systems. The identifiers of these objects are composed of the name of the system where the object originally came from plus a unique code for the object given by that system. Some learning management system (LMS) users, however, have records of objects in more than one system, and a link needs to be preserved to all of them. The 1.1 specification addresses this by allowing more than one identifier per object. Whether that solves the problems found in the way that various LMS products handle these identifiers remains to be seen. Tighter requirements for product compliance in this area should help.
A further set of changes concern new features. There is now, for example, a clear mapping of IMS Enterprise elements to the Learner Information Profile (IMS LIP) specification. This should make it easier for educators who need cumulative models of learning to properly integrate students' achievements over all relevant systems. The closer integration within IMS of these two specifications also bodes well for further improvements.
In a more technical improvement, there is now support within the Enterprise specification for user IDs, passwords and authentication and authorisation. This does not mean that IMS Enterprise systems will now be able to take care of authentication and authorisation themselves, but it does allow the various parts of an LMS to hook into a dedicated external authentication and authorisation solution. Further adoption of existing vendors' extensions to the original, 1.0 spec also means that multiple system and institution roles are now supported. Access control to the various parts of an LMS is therefore built into the underlying specification.
While all of these improvements help address the call for a tighter specification of the data that needs to flow between IMS Enterprise compliant systems, there are a few higher level challenges that need to be addressed too. First of these is a clear picture of what a product will and will not transfer properly. To this end the 1.1 spec has a clear requirement on vendors to indicate to customers, in a standardised form, which parts of the IMS Enterprise spec are supported and which are not. While a step forward, experience suggests that this is unlikely to be sufficient. For the crucial guarantee of interoperability, a standardised test bed would need to be developed and operated by a neutral organisation; something which has been lacking so far.
The greatest challenge to seamless interoperability at the enterprise level, however, is deliberately not addressed in this version of the IMS Enterprise specification: the lack of a communication model. While version 1.1 tightens up the specification of the form and labelling of data, there still is an urgent need for a standard way to transfer the data from one system to another. At the moment, it seems that version 1.01 compliant systems are better at facilitating wholesale migration from one vendor's product to a similar system from a different vendor, rather than different kinds of system being able to exchange data back and forth in real time. For that, customers are largely constrained to either rely on a complete LMS solution from one vendor, or strategic alliances between vendors of, say, student record systems, web portals and virtual learning environments (VLEs).
It is this communication issue that will be addressed in version 2.0 of IMS Enterprise, which is now scheduled to appear in draft form in the autumn. The delay is perhaps not surprising as it is a key part of IMS's stated shift to a much more ambitious behavioural approach. Where there used to be a reliance on the specification of the form of static data, compliance to IMS Enterprise 2.0 will also mean that products are expected to respond in predictable ways to events from other parts of an MLE. What form the communication model will take is not yet clear, but the recent announcement by MLE vendor Blackboard (which is influential in the IMS Enterprise committee) to adopt MIT's Open Knowledge Initiative (OKI) programming interfaces could be a pointer. The open source nature of OKI suggests that the present danger of a degree of vendor lock-in by proprietary data communication protocols could at least be diminished.
Clearly, for those contemplating the adoption of IMS Enterprise systems, timing is going to be an important issue. While version 1.1 compliant systems are likely to appear in the not-too-distant future (bearing in mind that 1.1 is at the draft stage), a case could be made for holding out for IMS Enterprise 2.0 compliant systems later on.