Subject: wrappers and extensibility
From: Crispin Weston (crispinw@dircon.co.uk)
Date: Thu 24 Feb 2000 - 21:27:57 MET
From: "Crispin Weston" <crispinw@dircon.co.uk> Subject: wrappers and extensibility Date: Thu, 24 Feb 2000 20:27:57 -0000
List address to send message to everyone: ifets-discuss@LISTSERV.READADP.COM
Details of current discussion: http://ifets.ieee.org/discussions/discuss.html
---------------------------------------------------------------------------
> >On educational wrappers. My view is that the educational wrapper will
very
> >often add interactivity to an essentially expositive resource.
>
> This sounds like a very intriguing premise. I don't quite see how that
could happen, at least automatically. I could see designers/authors adding
interactivity, but that then seems like creating a learning object, rather
than handling it through wrapping. Can you elaborate?
By 'wrapper' I did not mean to imply that the interactive layer would be
added automatically. My only experience of the word 'wrapper' is in a
programming context, when an extra layer of code is added (with some labour)
to an object, normally to alter its interface. I have not come across the
idea of automatic wrappers. I wanted to address the discussion about using
objects not specifically designed for educational purposes. Adding a
wrapper, to my mind, modifies an existing object to suit it to a new
context.
> >If learning objects are to
> >maximise their re-useability, they will need to be parameterised; but the
> >structure of the parameters is unpredicatable and cannot be written into
the
> >protocol. In this (and other) respects, the protocol must be extensible.
>
> To the extent that it's extensible, it's not reusable (though systems
ought to have graceful degradation back to the standard). There's a tough
tradeoff between wanting particular elements, and having an agreed, shared,
standard.
I accept that extensibility reduces the re-usability of objects between
different technical environments (different browsers or other executables).
But extensibility *increases* the reusability of objects in different
educational contexts. There are two different sorts of reusability here:
technical and educational. I think that is the latter sort of reusability
which is more pressing. The issue of technical re-usability can be
relatively easily solved by plug-ins: there is no reason why content should
not be accompanied by its proprietary run-time engine. COM and CORBA make
this kind of technical solution straightforward. We need standards like IMS
to ensure interoperability: not so that I can perform the educational
equivalent of loading a Lotus spreadsheet into Microsoft Excel.
Let me make my case for educational reusability more concrete. I am
developing a management system that communicates with interactive courseware
through an open standard. To maximise the reusabity of courseware, units
may want to offer the assignor (tutor or course designer) the opportunity to
pass parameters to the courseware unit as it is launched by the student.
This process here could be summarised as: unit + parameter settings (set by
the tutor) = a task which can be assigned to the student. As the developer
of the published protocol, it is very difficult to predict what sort of
parameters might be appropriate to individual courseware units. Someone
might develop a war-game simulation to form part of a military history
course: that unit might want parameters to set speed of enemy reactions,
weather conditions etc. Other units might want to change the amount of
reference material available, so that the same unit could be used in both
formative and summative contexts. Some units might be able to offer
selections of questions - just the easy ones, just the difficult ones - to
cater for differentiation. My solution to this problem is as follows: the
courseware unit comes together with a range of services. One of these is a
run-time engine; another is a custom parameter editor program. The
management system stores the default parameters for the courseware unit as
binary data (or as raw XML, perhaps). If the assignor (tutor or course
designer) wants to change the parameters, the management system fires up the
editor program, which understands the binary data passed to it, allows the
tutor to change the data (maximising the reusability of the unit by fitting
it for a different educational context) and passes the edited parameters
back to the management system as binary data. When the student comes to
launch the unit, the edited parameters are sent to the run-time engine,
which can interpret them appropriately. The run-time engine, the parameter
editor and the structure of the parameters themselves are all very
proprietary; but they also support a very high level of interoperability in
ways unforseen by the developer of the standard.
> Is there a reference to the OILS protocol?
OILS (Open Integrated Learning System) was developed by a consortium of
British companies in about 1994. The British Educational Suppliers
Association (BESA) still act as guardians of the protocol - but it never
really took off and it is gently receding into history. There is a moderate
amount of British software still around, however, which still support it.>
Crispin Weston
---------------------------------------------------------
Forum website: http://ifets.ieee.org/
Forum's contact person: kinshuk@massey.ac.nz
Info on Join/Leave List: http://ifets.ieee.org/maillist.html
---------------------------------------------------------
This archive was generated by hypermail 2a24 : Fri 25 Feb 2000 - 04:38:53 MET