Re: Eureka! Quizzer Item Types

[bruno <vernier@vernier>]

rhandeev@comp.nus.edu.sg wrote:

>  Introducing a second^H^H^H^H^Hhort form for the grammer specification
>  may be a Bad Thing (tm), because it introduces many compatibility
>  problems.

I hear you.  

>  It'd end up being no better that the graphics format business, with
>  101 formats, convertors, etc. and everybody using some
>  near-proprietary form that's different from the rest!

Ah but we are talking XML and convertors are only a few lines long. Further,
I am proposing only one API style deviation from pure XML and perhaps only
for as long as proper EDUML editors don't exist.

>  IMHO, it could be a better idea to keep the language specification
>  elegantly powerful and general right from conception, but rely on the
>  (eventual) EDUML writing tools to do their own simplifications.

Well, I'll gladly do so when such writing tools exist.  But since I am using
EDUML now for the courses I teach now, I can't afford to wait and I don't
want to go back to the old ways any more.  In fact, we can write an API <->
XML converter to keep in the back burner.

>  with an API for EDUML development, so developers can use EDUML
>  without bothering to write a parser.

But parsers are already written... and using a parser only takes a few
lines.  Compared to the hassle of writing the sample below, I still think
that for now, the <rpc> elements are a big time saver... as well as the only
(temporary?) breach of pure XML that is proposed.

> 	 <methodCall xmlns="some (possibly different) url">
> 	  <methodName/edu.multichoice>
> 	  <params>
> 	   <param>
> 	    <value type="list"> 
> 
> 	     <methodCall xmlns="yet another url">
> 	      <methodName/editors.methodCalls.list>
> 	     </methodCall>

> Then again, all these shortening should perhaps best be done within
> the EDUML editors and what-not applications yet to be born.

I naturally agree.  However, the API will need to be reassembled anyway
locally or remotelly for use by the quizzer.  It makes sense to use XML-RPC
for remote calls but introduces another layer of processing for just local
calls.  The matter is not cut and dry.

Bruno