5.3. Standards and Specifications
Much work has been done on defining standards and specifications for MLEs (see below for the difference between standards and specifications). Here we look at why they are an important component in developing an MLE, and the limits of standards. It is argued that they are probably the best way to work but that they are not sufficient to achieve interoperability and other work is also needed.
Standards and specifications
Many people use standards and specifications interchangably, however they do have precise meanings and it is important to understand the differences. Essentially standards are authoritative having been produced by a national or international organisation with the legal power to define standards. Specifications on the other hand have no legal status and may be defined by anyone.
Some specifications (including some from IMS) go on to become standards, but that may take many years. For instance, the standard for HTML is 2.0, while the world is using HTML 4.01 with all the additional features that it offers.
IMS
The IMS Global Learning Consortium develops and promotes the adoption of open technical specifications for interoperable learning technology. Several IMS specifications have become worldwide de facto standards for delivering learning products and services. IMS specifications and related publications are available from http://www.imsglobal.org.
CETIS
There is not scope here for a discussion of all the standards and their place in developing an MLE, and we recommend that you visit the CETIS: 'Centre for Educational Technology Interoperability Standards' web site. CETIS is a JISC funded service which:
helps to define the standards, ensuring that they meet the needs of the UK FE and HE communities
promotes their use within the community (including to vendors)
runs special interest groups covering each of the major areas that IMS addresses.
Considerable help is available from both CETIS and its special interest groups (SIGs), and anyone developing systems is urged to at least join their JISCmail lists.
5.3.1. Why use standards?
There are two approaches to developing systems that can communicate with each other. Either you can use an interface designed specially to meet your needs or you can use some standardised approach. Each has its advantages. Using standards (or open standards as they are sometimes called) confers a range of benefits in developing systems, and it is worth stating them briefly and then looking at the benefits of using a proprietary approach.
They key benefits are:
You are not tied into a single supplier as the system will work with anyone who is using the same standard. Some standards that work like this are so obvious that they are almost invisible. A good example is the electric socket. You can plug anything you want into a socket without worrying as toasters do not use different plugs to say televisions. The only time that this becomes visible is when you travel abroad and find a different standard in use, which can be overcome using a travel adapter.
Migration is easier related to the last point, you will be able to change component of your system more easily if they are using the same standard, and are unlikely to have to expend as much effort compared to incorporating a new component within a proprietary environment.
Development costs are shared. Instead of having to fund the development costs for your particular solution the costs are shared between everyone using the system.
Future proofing. Standards are developed to be as widely applicable as possible, and are continually under review and revision to meet changing needs. This means that the standard is likely to meet your needs and that many people have been thinking about it to solve the problem. You are therefore likely to find it easier to change as your needs develop.
In short then, open standards give greater flexibility and reduced long term development and support costs, and prevent you getting 'locked into' a single supplier.
The alternative approach is to use specially designed systems (often referred to as proprietary). These can be more efficient as they is designed to do exactly what you want and it may as a result also be easier to implement in the short term. The major disadvantages are:
Only a limited number of systems will be able to make use of it which may mean that you either have a large implementation task when you buy additional parts of the MLE or that you are unable to use a large proportion of the systems on the market.
All the adaptation and improvement has to be done for these systems, you are not able to take advantage of developments that are being undertaken at a national or international level. The advantage of standards is that any system that is using them will (in theory) work with any other system that is using the same standards. Of course it is not that simple (see the limits of standards below).
Where vendors are working towards the same standards then it should be much simpler to implement the connectivity you need to make an MLE work. There is also the advantage that the standards are continuously being reviewed and updated in the light of changing needs across the community and that you are likely to find many of the things that you want to do are enabled as the standards are updated.
5.3.2. Which standards
Standards have an important role to play in developing an MLE as they allow the developer to work with systems from other developers that make use of the same standards, without which considerable effort will be needed to move data around the various systems which make up the MLE. As an example, if there is not a standard way of handling dates it is not clear whether 03/06/2003 is 3 June or 6 March. With the complexity of the systems involved in MLEs it is very expensive to link together systems which are not using standards as a separate development has to be undertaken for each pair.
If College 1 has student record system SRS1 and financial system SF1 and VLE VLE1, while college 2 has student record system SRS2 and financial system SF2 and VLE VLE2 and college 3 has student record system SRS2 and financial system SF1 and VLE VLE1. Without standards 6 pairs of interfaces would be needed:
SRS1 <-> SF1,
SRS1 <-> VLE1,
SRS2 <-> SF2,
SRS2 <-> VLE2,
SRS2 <-> SF1
SRS2 <-> VLE1
Standards fall into a number of areas:
data interchange formats
data exchange
data transport
security
It is worth looking at the first two of these, and at the limits of standards. It is beyond the scope of this work to look at transport and security, and you are advised to refer to the JISC's Authentication, Authorisation and Accounting (AAA) Programme for security.
Data interchange formats
CETIS, the Centre for Educational Technology Interoperability Standards, has been doing considerable work in defining and promoting the use of IMS in the UK, ensuring that IMS meets UK FE and HE needs and explaining how to make effective use of IMS. You are referred to the CETIS web site for details of all these standards.
Data exchange
Currently there is no single standard for transferring the data from one system to another, and a variety of approaches have been adopted from manually exporting / importing through the use of ftp to fully automated processes.
It would appear that SOAP (Simple Object Application Protocol) is likely to be the eventual solution as this is the way that web services are moving.
5.3.3. Compliance with standards
The relevant standards (notably IMS) are still very immature which means that they are still changing as they get further refined and developed. New versions of the standards may be significantly different from older ones, so that systems which are at first glance using the same standards will not work together.
Even where they are using the same version the immaturity means that different interpretations are possible in some parts of the standard leading to incompatibility. Should both of these problems have been overcome many vendors only implement part of the standards and unless both include all the parts that you need they still will not work together.
To address this CETIS has organised a number of 'plugfests' where a variety of suppliers come together and actually exchange data between their systems and identify any issues that need to be addressed.
In the long run it is likely that compliance testing will be developed at which point you should look for products which have been certified. Unfortunately this is still some way off and in the interim there is little alternative to actually testing whether interoperability works prior to purchase.
5.3.4. The limits of standards
While open standards are the best approach for developing MLEs there are a number of problems with them, and they will only take one so far in the implementation of MLEs. You need some understanding of these issues if you are to achieve a successful implementation.
Most of the points addressed here were highly visible in the FE MLE programme run by the JISC which primarily looked at using IMS to link together VLEs and student record systems, but the issues will be found in many other areas too.
Many of the standards are not standards at all - most of the standards in the area of learning technologies are not official standards, they are specifications produced by bodies with no legal standing. This includes IMS which is funded by a number of universities and suppliers and the JISC. Although many of the 'standards' are really specifications they will be referred to as standards for the sake of simplicity.
Many of the standards are poorly developed. Standards are typically arrived at through a consensual process, which attempts to draw in as many of the participants as possible. This is very slow, with the result that we are often having to develop systems based on drafts of specifications which are likely to change. Until people start implementing the standards in their systems it is not really possible to know where their weaknesses lie, and so what changes may be needed.
Many standards contain ambiguities - this is related to the previous point. However ambiguities cause a particular set of problems as they allow different vendors to implement the standards in different ways which are incompatible with each other. Thus, although two systems both claim to be compliant with a particular standard (and may indeed be so) they will not actually interoperate with each other.
Version control - standards are moving very quickly, with new versions of many of them coming out twice a year. They are not always completely backward compatible so that different versions of the same standard may well not work together. This causes problems during purchase and when it is necessary to upgrade systems.
Lack of compliance certification - many systems claim compliance with the relevant standards, but it is not clear what this means unless they are certified. For instance, Wi-Fi Alliance certifies equipment as being compliant with 802.11 wireless standard and that they do interoperate. There is no similar body covering educational technology standards.
Competing standards - many bodies have an interest in developing standards, and in the area of educational technology these include the Institute of Electrical and Electronic Engineers (IEEE), IMS, ADL (who produce SCORM). Even when they are attempting to work together it still takes a long time for their various standards to converge.
Incompleteness - the standards may not cover everything that needs to be addressed so that some of the work has to be done outside the standards, or the standards have to be stretched to cover the issue.
Multiple standards - there is a need to use different standards to cover different aspects of the problem (IMS for data formatting, SOAP for transport etc). It may be difficult to tie these together.
Despite this long list of problems there is rapid progress being made on many of these issues, and it is worthwhile taking an open standards approach.
The MLEs in FE Case Studies found that although institutions are aware of IMS standards there is little evidence, from these case studies, of widespread adoption of standards based approaches. This may be connected with vendor lock-in.
Follow this link for key resources for this section (these open in a new window)
Follow this link for more resources for this section (these open in a new window)
