Re: Eureka! Quizzer Item Types

[Rhandeev Singh <rhandeev@comp.nus.edu.sg>]

> Eureka!

Way cool, Bruno :D  EDUML is beginning to look powerful.

<purist mood>

<devil's advocate>

 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.

 Then we'd have to worry about a third mutila^H^H^H^H^Huch shorter
 form, and a fourth, and a fifth... just to make it easier for the
 user.

 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!

 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.

 These may present the information to the users in whatever
 proprietary shortforms they want, e.g. we might even end up with a
 visual EDUML IDE; as long as all save crisp, clean, pure EDUML :)

 A Golden Key (tm) to standardization is to provide e.g. a C library 
 with an API for EDUML development, so developers can use EDUML
 without bothering to write a parser.

</devil's advocate>

I like the nesting support, e.g. we could do things like

    <rpc>
     <methodCall xmlns="some url">
      <methodName/edu.essay>
      <params>
       <param name="question">
        <value type="text"> Briefly discuss the LPF's argument against 
			    software patents
	</value>
       <param name="editor_spawn_method">
        <value type="methodCall">

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

	     <methodCall xmlns="yet another url">
	      <methodName/editors.methodCalls.list>
	     </methodCall>

	    </value>
	  </params>
	 </methodCall>

      </params>
     </methodCall>
    </rpc>

So, the second edu.essay parameter is the result of choosing a
methodCall from a list of methodCalls, which is obtained through
another rpc methodCall.

(OK, maybe it's a bad idea to try to edu.multichoice() a list of
methodCalls unless they have <label>s, but you get the idea.) 

The proposed short form forces the parser to know about the edu.whatever
method calls; maybe this compromise is better (like I know anything about
XML yet :P Massive corrections probably required):

  <rpc> call("rpc://rpc.seul.edu", "edu.essay", 

	     "Briefly discuss the
		       LPF's argument against software patents",

	     call("rpc://rpc.seul.edu", "edu.multichoice",
		  call("rpc://editors.seul.edu",
		       "editors.methodCalls.list")))
  </rpc>

To further Mutilate (tm) the language, maybe it would be less
laborious for the typist if we could allow some fields, e.g. the URL,
to carry forward like so:

  <rpc> <url/"rpc://rpc.seul.edu">

	call("edu.essay", "Briefly discuss...", 
	     call("edu.multichoice",

		  callurl("rpc://editors.seul.edu",
			  "editors.methodCalls.list")))
  </rpc>

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

</purist mood>

Just my 2 1/2 cents :-)

---
Rhandeev Singh                      rhandeev@comp.nus.edu.sg
Linux User Group                    http://linux.comp.nus.edu.sg
School of Computing                 http://www.comp.nus.edu.sg/~rhandeev
National University of Singapore