So far as I can tell, it is impossible (using GIFT) to import either calculated questions or questions with graphics. Is this true, or have I just failed to find the right documentation? If it is true, are plans afoot to remedy these defects?
Thanks, Alan
There is no way of importing calculated questions. (i'm not sure about moodle xml format, probably since it borrows from back up and restore.)
You may insert graphics urls into gift formated questions and import them.
You may insert graphics urls into gift formated questions and import them.
"since it borrows from back up and restore"
Not true. It is completely discrete. This was intended to be a clean and simple XML format. It does, however, handle (almost) all features including images and calculated questions.
Not true. It is completely discrete. This was intended to be a clean and simple XML format. It does, however, handle (almost) all features including images and calculated questions.
You are correct but to call it a "defect" is to misunderstand the purpose of the GIFT plugin.
It is intended to be a way to hand-code (a limited range of most-used) questions quickly and (reasonably) intuitively. It has already been stretched to the point where almost any text will parse as something (not great from an error/feedback POV). To stretch this further would, IMO, make the syntax very confusing.
Having said that, if somebody cares to propose an elegant solution that extends the syntax for new features we'll have a serious look at it.
It is intended to be a way to hand-code (a limited range of most-used) questions quickly and (reasonably) intuitively. It has already been stretched to the point where almost any text will parse as something (not great from an error/feedback POV). To stretch this further would, IMO, make the syntax very confusing.
Having said that, if somebody cares to propose an elegant solution that extends the syntax for new features we'll have a serious look at it.
GIFT seems an excellent tool for that limited purpose. I was initially delighted to discover it, because GUIs drive me crazy, and I saw GIFT as a way to avoid the Moodle GUI. The current GIFT is not quite up to that job.
You asked for suggestions regarding syntax for importing calculated questions. GIFT has a lovely syntax, but if I were redesigning it I would make it a bit more wordy. The current GIFT has very few keywords, and this surely makes it hard to extend. Perhaps it would be easier to write a separate language for importing calculated questions. Then users could keep calculated questions in a separate file, and import them in a separate operation.
If I were writing the code, I might invent something like this:
# How a calculated question might look if I were designing a
# language for importing quiz questions into Moodle.
#Define probability distribution name "uniform_int"
@def_dist{uniform_int}{uniform(1,10),digits=0}
# A calculated question
@begin{calculated}
You asked for suggestions regarding syntax for importing calculated questions. GIFT has a lovely syntax, but if I were redesigning it I would make it a bit more wordy. The current GIFT has very few keywords, and this surely makes it hard to extend. Perhaps it would be easier to write a separate language for importing calculated questions. Then users could keep calculated questions in a separate file, and import them in a separate operation.
If I were writing the code, I might invent something like this:
# How a calculated question might look if I were designing a
# language for importing quiz questions into Moodle.
#Define probability distribution name "uniform_int"
@def_dist{uniform_int}{uniform(1,10),digits=0}
# A calculated question
@begin{calculated}
# declare variables of type uniform_int
@uniform_int{a,b,c}
# generate 20 data items by sampling from relevant distributions
@generate_data{20}
# Question text
What value of $x$ maximizes $f(x) = {a} + {b}x - {c}x^2$?
# Answer contains value, relative (or absolute) tolerance,
# and response.
@answer{{b}/(2*{c}), rel_tol=0.01, response="Excellent!"}
@end{calculated}@uniform_int{a,b,c}
# generate 20 data items by sampling from relevant distributions
@generate_data{20}
# Question text
What value of $x$ maximizes $f(x) = {a} + {b}x - {c}x^2$?
# Answer contains value, relative (or absolute) tolerance,
# and response.
@answer{{b}/(2*{c}), rel_tol=0.01, response="Excellent!"}
Of course, the import/export formats are a plug-gable resource. You could write (or pay/persuade someone to write) this option.
After my last post, it occurred to me that I had not really responded to Howard Miller's request. Howard asked for proposed formats not for a totally new language but for an extension to GIFT that could handle calculated questions. Here is an extension that might work:
//Define random variable type "uniform_int"
$DISTRIBUTION: UNIFORM_INT, uniform(1,10), digits=0
// The proposed format adds a new optional field just after the "label"
// field. This field can contain commands that define random variables
// and generate samples from these random variables.
::Calculated optimization question::
$UNIFORM_INT: a,b,c // define random variables of type UNIFORM_INT
$GENERATE_DATA: 20:: // generate 20 samples
What value of $x$ maximizes $f(x) = {a} + {b}x - {c}x^2$?
{#{b}/(2*{c}):0.01#"Excellent!"}
(The dollar signs should be double-dollar-signs.)
//Define random variable type "uniform_int"
$DISTRIBUTION: UNIFORM_INT, uniform(1,10), digits=0
// The proposed format adds a new optional field just after the "label"
// field. This field can contain commands that define random variables
// and generate samples from these random variables.
::Calculated optimization question::
$UNIFORM_INT: a,b,c // define random variables of type UNIFORM_INT
$GENERATE_DATA: 20:: // generate 20 samples
What value of $x$ maximizes $f(x) = {a} + {b}x - {c}x^2$?
{#{b}/(2*{c}):0.01#"Excellent!"}
(The dollar signs should be double-dollar-signs.)
Well, hmmm, yes.... I suppose it gets the job done but pretty it is not. It may be reasonable to propose a general form for GIFT extensions of which this would be an instance. This could end up with GIFT itself having plugins which is getting a bit bizarre perhaps.
It doesn't help that calculated questions themselves are in the realm of the arcane
It doesn't help that calculated questions themselves are in the realm of the arcane
One could make the syntax prettier by moving the commands out of the question itself:
// Define random variable type "uniform_int"
$DISTRIBUTION: UNIFORM_INT, uniform(1,10), digits=0
// Declare random variables
$UNIFORM_INT: a,b,c
// Specify the number of samples per question
$SAMPLES_PER_QUESTION: 20
// Parser recognizes this as a calculated question because it
// refers to {a}, {b}, and {c}, which were declared above.
::Calculated optimization question::
What value of $x$ maximizes $f(x) = {a} + {b}x - {c}x^2$?
{#{b}/(2*{c}):0.01#"Excellent!"}
$DISTRIBUTION: UNIFORM_INT, uniform(1,10), digits=0
// Declare random variables
$UNIFORM_INT: a,b,c
// Specify the number of samples per question
$SAMPLES_PER_QUESTION: 20
// Parser recognizes this as a calculated question because it
// refers to {a}, {b}, and {c}, which were declared above.
::Calculated optimization question::
What value of $x$ maximizes $f(x) = {a} + {b}x - {c}x^2$?
{#{b}/(2*{c}):0.01#"Excellent!"}
I'm not sure that GIFT is the right place to start with this. It is meant to be a simple format that covers a subset of what Moodle questions can do.
The one format we have that is can completely represent Moodle questions is the Moodle XML format.
Now, XML is a sucky format to type. it is. I wonder if we could easily define a new format that is basically the same, but without the verbosity. terse: perhaps.
Then, the importer would work be converting the short and typable format to the normal XML, and then feed it to the XML importer.
The one format we have that is can completely represent Moodle questions is the Moodle XML format.
Now, XML is a sucky format to type. it is. I wonder if we could easily define a new format that is basically the same, but without the verbosity. terse: perhaps.
Then, the importer would work be converting the short and typable format to the normal XML, and then feed it to the XML importer.
+1
I think that GIFT has gone about as far as it can go. Anything else would be contrived.
I'm not sure what the converter would look like. Would this be a desktop app of some sort? That brings a whole raft of issues all by itself. Example, the current Office macro based solutions are strictly Windows only.
I think that GIFT has gone about as far as it can go. Anything else would be contrived.
I'm not sure what the converter would look like. Would this be a desktop app of some sort? That brings a whole raft of issues all by itself. Example, the current Office macro based solutions are strictly Windows only.
No, I was thinking of a new import format, very roughly like:
class qformat_whatever extends qformat_xml {
function readquestions($lines) {
// Convert $lines from our new format to XML.
parent::readquestions($lines);
}
}
Write is slightly harder to implement. Actually, perhaps not:
function writequestion($question) {
$out = parent::writequesion($question);
// Convert $out from XML to our new format, perhaps using XSLT.
return $out;
}
class qformat_whatever extends qformat_xml {
function readquestions($lines) {
// Convert $lines from our new format to XML.
parent::readquestions($lines);
}
}
Write is slightly harder to implement. Actually, perhaps not:
function writequestion($question) {
$out = parent::writequesion($question);
// Convert $out from XML to our new format, perhaps using XSLT.
return $out;
}
Most of the Excel and Word based solutions for creating questions are Windows-based because they use the Office XML library to locally convert the Word or Excel file into Moodle XML format. Moving the conversion process to the server side would avoid this problem, and enable support for MacOS.
A purely plain-text based approach to question authoring ignores the reality that most people use a rich word-processor (or spreadsheet), and would prefer to continue using it, and the full facilities it offers.
A tabular layout for questions is worth consideration. I defined a table layout for questions in my Word template [1], intended to be clear, simple and robust enough for children to use.
But the same tabular layout could be used in OpenOffice or any HTML editor. Both Word and OpenOffice tables can be saved as HTML tables, and a simple
XSLT stylesheet could be used to convert such tables into Moodle Question XML.
This stylesheet can use the position of each cell to identify the type of the information, e.g.
- heading row 1, cell 1 is the question stem,
- heading row 1, cell 2 is the question type,
- body rows 1 .. 4, are answers for MC questions,
- with column 2 for right or wrong answer, column 3 for feedback, and column 4 for a grade/fraction, etc.
In fact, that is the process I use to convert Word files via HTML tables into Moodle Question XML format.
If there was a standard HTML table definition of what each question type looked like, then anyone could develop a front-end (in Word, Excel, OpenOffice, DreamWeaver, or even within a rich-text field in a Moodle form), that generates a table in that format much more easily than generating the current Question XML format directly, either manually or programmatically.
A Moodle server could then offer standard import and export facilities for the HTML table format only, and leave the client-side interface for creating/editing questions to others.
[1] www.moodle2word.net
A purely plain-text based approach to question authoring ignores the reality that most people use a rich word-processor (or spreadsheet), and would prefer to continue using it, and the full facilities it offers.
A tabular layout for questions is worth consideration. I defined a table layout for questions in my Word template [1], intended to be clear, simple and robust enough for children to use.
But the same tabular layout could be used in OpenOffice or any HTML editor. Both Word and OpenOffice tables can be saved as HTML tables, and a simple
XSLT stylesheet could be used to convert such tables into Moodle Question XML.
This stylesheet can use the position of each cell to identify the type of the information, e.g.
- heading row 1, cell 1 is the question stem,
- heading row 1, cell 2 is the question type,
- body rows 1 .. 4, are answers for MC questions,
- with column 2 for right or wrong answer, column 3 for feedback, and column 4 for a grade/fraction, etc.
In fact, that is the process I use to convert Word files via HTML tables into Moodle Question XML format.
If there was a standard HTML table definition of what each question type looked like, then anyone could develop a front-end (in Word, Excel, OpenOffice, DreamWeaver, or even within a rich-text field in a Moodle form), that generates a table in that format much more easily than generating the current Question XML format directly, either manually or programmatically.
A Moodle server could then offer standard import and export facilities for the HTML table format only, and leave the client-side interface for creating/editing questions to others.
[1] www.moodle2word.net
Tim Hunt suggests writing a stand-alone utility to translate from some plain-text format into XML. Would this be any easier to code than importing straight into Moodle?
Eoin Campbell argues against a plain-text format and in favor of one based on Windows or Excell. Kind of defeats the purpose from my perspective. The beauty of a text-based language like GIFT is that it allows the GUI-averse to avoid GUIs. A solution based on Word would not do that. In addition, it would make Moodle dependent on proprietary software.
Eoin Campbell argues against a plain-text format and in favor of one based on Windows or Excell. Kind of defeats the purpose from my perspective. The beauty of a text-based language like GIFT is that it allows the GUI-averse to avoid GUIs. A solution based on Word would not do that. In addition, it would make Moodle dependent on proprietary software.
I didn't suggest anything stand-alone. I suggested a new text format that would import directly into Moodle, and which could be implemneted quite easily because it would internally use the all the Moodle XML format code, which already supports (and always will) all the features of all the Moodle question types.
I'm not sure that I can add anything terribly useful to the discussion, other than my own use-case for GIFT.
I rely on GIFT in a very significant way, generating a problem "type" on a spreadsheet. The problem uses random parameters generated by the spreadsheet. Its then a simple copy and paste to generate the question bank, and the result is saved as a text file.
In the background there are a bunch of macros to handle the messy algebra and formatting and the horrifying mixture of escaped curly brackets (related to the TeX filter) and answer curly brackets. The system is arcane, but it works because of the simplicity of GIFT's text format.
I often cast a hopeful eye on other question systems, but the lack of flexibility or the increased complexity have an exponential impact on development time (and conversely tend to limit flexibility). This includes macro-to-format-a-question interfaces and anything with a GUI.
So I guess the summary would be to keep it as simple and robust as possible.
I rely on GIFT in a very significant way, generating a problem "type" on a spreadsheet. The problem uses random parameters generated by the spreadsheet. Its then a simple copy and paste to generate the question bank, and the result is saved as a text file.
In the background there are a bunch of macros to handle the messy algebra and formatting and the horrifying mixture of escaped curly brackets (related to the TeX filter) and answer curly brackets. The system is arcane, but it works because of the simplicity of GIFT's text format.
I often cast a hopeful eye on other question systems, but the lack of flexibility or the increased complexity have an exponential impact on development time (and conversely tend to limit flexibility). This includes macro-to-format-a-question interfaces and anything with a GUI.
So I guess the summary would be to keep it as simple and robust as possible.
Eh, no, I didn't argue in favour of a format based on Windows or Excel. Perhaps I wasn't clear enough. I suggested a *structured XHTML table format* as a new import option, which would act as a front-end to the current Moodle Question XML import format.
Using XHTML as a format would allow many rich-text features (graphics, bold, paras, etc.) to be included in any part of a question, which is not the case with the current web GUI, or in any of the plain-text formats, at present. The original query in this thread was about this particular issue, I think.
XHTML would also be quite compatible with a variety of front-end editing interfaces on any platform, such as Word (on Windows or Mac), OpenOffice (on Win/Mac/*nix), Excel (Win/Mac), and with any HTML editor or plain-text editor.
This compatibility would be quite useful, because many people already use a wordprocessor for much of their work, and being able to use it for managing banks of Moodle quiz questions too would be very convenient. The web GUI for quiz questions operates on a one-question-at-a-time basis, which is slow and tedious, while many people want to work on a whole bank of questions at a time. Using OpenOffice or Word to maintain a bank of questions in a single file, and simply saving the file as XHTML in order to import it into Moodle, seems like a nice convenience to me.
Using XHTML as a format would allow many rich-text features (graphics, bold, paras, etc.) to be included in any part of a question, which is not the case with the current web GUI, or in any of the plain-text formats, at present. The original query in this thread was about this particular issue, I think.
XHTML would also be quite compatible with a variety of front-end editing interfaces on any platform, such as Word (on Windows or Mac), OpenOffice (on Win/Mac/*nix), Excel (Win/Mac), and with any HTML editor or plain-text editor.
This compatibility would be quite useful, because many people already use a wordprocessor for much of their work, and being able to use it for managing banks of Moodle quiz questions too would be very convenient. The web GUI for quiz questions operates on a one-question-at-a-time basis, which is slow and tedious, while many people want to work on a whole bank of questions at a time. Using OpenOffice or Word to maintain a bank of questions in a single file, and simply saving the file as XHTML in order to import it into Moodle, seems like a nice convenience to me.