On 23 Nov 01, at 15:57, George Wraith wrote:
> Dear all
>
> My concern is that there still appears to be no common agreement between all
> vendors to enable them to incorporate the IMS specifications into their differing
> software applications, so as to allow them to interoperate with other systems.
> The differing interpretation of the IMS specifications is now the major problem
> within our Interoperability pilot. Without these being jointly agreed by all parties
> involved we will more than likely just end up with separate systems that can
> exchange data, eventually but certainly not automatically. This being the case I
> could not see the interoperability of differing systems ever getting off the ground
> to the extent Colleges would want to buy them, and students would want to use
> them. It points most Institutions back down the path of "proprietary lock-in".
Hi - are you sure that IMS is supposed to do more than enable
separate systems to exchange data? I mean, I am not aware that
IMS is designed to facilitate automatic data exchange. My
understanding is that IMS is a standard. To be compliant, in fact, a
system or database need only hold a information in a few IMS
compatible fields. Thus simply holding person details (e.g. author),
title, description and type would make would make a record IMS
compliant, even though two systems holding that same information
may be completely different, and not necessarily be able to talk to
each other.
The point is that the two systems AT LEAST share that common
record and data types, which they may not have done before.
But maybe I've got that completely wrong!?
The key to all this lies as you say in the XML, and in developing
clear and agreed taxonomies (for example, a taxonomy of "types"
as stated above). That I believe is the task that the MEG, the JISC
MLE Steering Group and the CETIS Special Interest Groups are
attempting to address.
Peter Jackson
RESULTs
(national portal for learning technologists in HE)
University of Warwick
(and formerly of FERL!)
>
> To give the community some idea as to the practicalities here is a brief example
> of the problem we have come across and STILL have no solution for, despite
> over a year of discussion.
>
> The major problem lies in the differing interpretations of the IMS specifications. In
> brief, the XML file generated by our MIS suppliers export utility which takes the
> data from our MIS has a different interpretation of the IMS Enterprise
> specifications. It therefore produces data in a format that our VLE providers
> import Utility does not recognise because of their interpretation of the IMS
> Specifications. Therefore what is required in order to import this XML file into the
> VLE is raw editing of the XML file. We have managed to achieve the importing of
> this student data after editing, but it was a long and arduous process. It
> demonstrates the need for a speedy agreement on the IMS specifications.Both
> vendor parties are genuinely working as best they can given the moving
> platform on which they are developing their software.
>
> My point is there needs to be a solid platform for vendors to base there
> developments. It is over a year since the FERL/BECTA conference at which all
> vendors initially got together to achieve this objective, but there does not seem to
> be any strategic direction been given by any of the various organisations
> concerned, and hence very little appears to have been achieved.
>
> Do we throw away any chance of true interoperability now? Comments please.
>
>
>
> George Wraith
> Product Development Manager
> New College Durham
>
> ***************** List information: *****************
> Remember - replies go by default to the entire list.
> Access the list via the web on http://www.jiscmail.ac.uk/lists/vle.html
> To unsubscribe, email [log in to unmask] with the message: leave vle
***************** List information: *****************
Remember - replies go by default to the entire list.
Access the list via the web on http://www.jiscmail.ac.uk/lists/vle.html
To unsubscribe, email [log in to unmask] with the message: leave vle
|