skip to main page content CETIS: Click here to return to the homepage
the centre for educational technology interoperability standards

skip over the long navigation bar
Home
News
Features
Events
Forums
Reference
Briefings
Press centre

Inside Cetis
what is Cetis?
Contact us
Cetis staff
Jobs at CETIS


 




Syndication
XML: Click here to get the news as an RSS XML file XML: Click here to get the news as an Atom XML file iCAL: Click here to get the events as an iCalendar file

Background
what are learning technology standards?
who's involved?
who's doing what?

CETIS Groups
what are cetis groups?
what difference can they make?
Assessment SIG
Educational Content SIG
Enterprise SIG
Metadata SIG
Life Long Learning Group
Portfolio SIG
Accessibility Group
Pedagogy Forum
Developer's forum

Subjects
Accessibility (310)
Assessment (74)
Content (283)
Metadata (195)
Pedagogy (34)
Profile (138)
Tools (197)
For Developers (569)
For Educators (344)
For Managers (339)
For Members (584)
SCORM (118)
AICC (18)
CEN (34)
DCMI (36)
EML (47)
IEEE (79)
IMS (302)
ISO (21)
OAI (24)
OKI (20)
PROMETEUS (12)
W3C (37)

print this article (opens in new window) view printer-friendly version (opens in new window)

Consolidation before the leap; IMS Enterprise 1.1

image: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.

Related items:

Comments:

No responses have been posted

copyright cetis.ac.uk
Creative Commons License This work is licensed under a Creative Commons License.

syndication |publisher's statement |contact us |privacy policy

 go to start of page content