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
Press centre

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


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

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

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)
W3C (37)

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

OKI and IMS, wires and sockets revisited

Two years ago, at the alt-i-lab conference in Boston, the relation of the Open Knowledge Initiative's (OKI) Open Service Interface Definitions (OSIDs) with IMS's specifications was discussed at length. Now, just before this year's alt-i-lab conference, the OKI - IMS relation is finalised at the process and part of the spec level. One the wider, technical level, the merits of combining OSIDs with web services will be demonstrated during alt-i-lab in Sheffield.

The new IMS and OKI collaboration has two aspects: the hosting of the OSID maintenance process and the convergence of the OKI OSIDs and IMS specifications. With regard to the former, the solution is simply for IMS to host a process on its website whereby requests for changes or ideas for new OSIDs are captured, and then routed through a process that remains specific to the OSIDs.

In essence, the OKI process consists of a few document cycles to take a contributed idea to a modified or all-new released OSID. At the crucial stage of going from idea to a Request For Consideration (RFC; essentially a proto-spec), the deciding group of people are the OKI Experts Group; 'a group of architects and developers selected because of their understanding of the goals of the OSIDs'. The experts group is also responsible for taking the RFC forward through the rest of the process. Some people will appreciate the consistency that the crucial role of the experts group will bring, others are likely to feel that it makes the process insufficiently open.

At the spec level, one of the differences between the OKI OSIDs and the IMS specs has always been the choice of base technology; IMS specs are all based on cross-platform XML, and the OSIDs on Java. More widely, classic IMS specs were all about structured data, and OSIDs are all about application programming interfaces (APIs).

This is set to change somewhat with today's release of XML bindings of the OSIDs. These XOSIDs provide an abstract, programming language neutral representation of the OSIDs that is effectively the new source version of the OKI specs. That is, the XOSIDs themselves won't be used in applications to provide interoperability, but they will be used as the source from which language specific bindings are derived.

As a result, the time it takes to generate OSIDs for languages other than Java has been slashed considerably. Some OSIDs have already been ported to languages such as PHP, C# and Objective C, and are used in production systems. Note that implementing an OSID in such a language doesn't mean that it will then be interoperable with OSID adapters that have been written in other languages. Language bridges such as the Mac world's widely used Objective C to Java bridge needs to be used for such a purpose.

Still, the XML based nature of the XOSIDs also opens the possibility of the creation of new XOSIDs as part of the new IMS specification workflow. In the latter, a new specification's datamodel and behaviour are specified in abstract UML first, and then transformed to the XML Schema definition and WSDL files that Web Service enabled systems use to interoperate. Deriving OKI style API descriptions (i.e. XOSIDs) at the same time should be perfectly possible, provided that the IMS spec fits with the existing OSIDs and how they are factored.

Which of course raises the older question of how OSIDs relate to Web Services in practice. Part of the answer will be demonstrated at alt-i-lab in Sheffield, were a fair number of search tools will be coupled to an even larger number of repositories via the repository OSID. The not-so-secret sauce that makes this possible is the fact that each of the relatively simple and innovative search tools only has to implement the one OSID, and that each repository needs to supply only one OSID adapter to the search tool.

Great stuff, but greater still is the fact that some of the repositories use standardised protocols to expose their data and functionality; a web service. Once there is one OSID adapter for such a service, adding any new repository that also uses the standardised web service is a doddle.

OKI's Jeff Kahn demonstrated exactly that by taking an existing SRW OSID adapter, a look at the Resource Discovery Network (RDN)'s SRW interface and after some twiddling, one tweaked OSID adapter exposed vast parts of the JISC's resource collection to any repository OSID compliant search tool. We'll delve into more of the detail nearer the actual demo.


A joint press release about the IMS/OKI collaboration on OSID maintenance.

The IMS page that hosts XOSID information, including links to the current (version 2.0) XOSIDs, Java OSIDs and the XSLT used to get from one to the other.

A press release about the forthcoming alt-i-lab demo.

Related items:


No responses have been posted

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