[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [school-discuss] Static vs dynamic EduML
> XIAO Gang said,
> > Therefore, room should be reserved in the format of the (EduML?)
> > exercises, to allow for definition of (at least) random parameter
> > processing and multiple forms of input.
On Sun, Feb 10, 2002 at 04:15:27PM -0000, Douglas S. Blank wrote:
> One idea that could go hand-in-hand with this is to build into EduML the idea
> of "executable content". For example, if one added a new tag, with it would
> come a URL pointing to a definition of functionality. Or the tag could have
> code associated with it (embedded in the EduML) to actually do the functions
> associated with it.
Thank you Xiao Gang and Doug Blank for bringing up this hugely important
This is the problem domain that was tackled with CORBA and friends a few
years ago, and then by Jini (Java RMI) and Microsoft .NET, RPC (Remote
Procedure Calls) and SOAP and more alphabet soup to come, I am sure.
The randomness (and any other intelligent processing being transferred by
Eduml) can either be:
- "pre-processed" and then sent in "rendered" form, or
- "post-processed" (each time it is "read") by a remote procedure call to the
server than knows how do the processing.
Futher, I think in the future we may also want to affect and be affected by
ongoing processing (where pre-processing or post-processing won't be good
enough; such as in real-time multi-user educational games or quizzes)
So Eduml should also include the upcoming jabber XML protocol and similar instant
My not-so-secret hope is that members of this mailing list will see the
construction of Eduml as simply assembling the best parts of the most accepted
XML standards out there, making slight adjustments to fit the opensource
model and educating each other on its use.
We will soon reach exercise 4 where we decide (participatory democraticacy
style) which of the current XML for education standards Eduml is to be based
on (and I am known to favor IMS in this regard) and what slight changes need
to be made ... and we will go on to write "tie-in" drivers for our various
projects to gain experience actually interoperating with each other and
compiling developers notes on what works and what does not .