As a result of a discussion with Gustav, I wanted to make a few notes and comments for discussion.
We want to make import and export a bit more intuitive and modular. Import/export extends a class and question types now do too, but the two functions don't cross paths. I want to make a clearer route for question writers to be able to add the new type into the import/export types where appropriate.
This is tricky stuff. My initial idea is something like (and this is a germ of an idea) to only have one import export format - XML - and convert to and from this format. I could use XSLT or I could use PEAR::XML_Transformer, but neither are currently a requirement.
Any thoughts appreciated.
The tricky bit is that both questiontypes and export formats should be modular. So we really need one script file for each questiontype-format combination. They all need to be in individual files so that a authors of new questiontypes can extend existing export formats and authors of new export formats can extend existing question types simply by adding new files rather than by adding to existing files. That will make it easier to just drop in the new question types and export formats. This means a lot of individual files but that isn't really a big problem, is it?
Having thought some more about this - I had kind of come to this conclusion, although I am rather worried about import, as quite a lot of work must (potentially) be done before you know what the questiontype is - in fact actually dealing with the question once its type is established may be trivial. I'm unsure what that would look like.
I particularly want to eradicate the hard-coded lists of questiontypes, this should be automatically generated from the available questiontypes (each of which [should] override the name method).
On top of this there's quite a bit of tidying up to do of the existing scheme. It's not the nicest bit of Moodle - you shouldn't be offered formats that don't exist and you should be shown where your exported file is - and that's just what I can think of off the top of my head.
I need to think some more about the architecture of all this
I particularly want to eradicate the hard-coded lists of questiontypes, this should be automatically generated from the available questiontypes (each of which [should] override the name method).
On top of this there's quite a bit of tidying up to do of the existing scheme. It's not the nicest bit of Moodle - you shouldn't be offered formats that don't exist and you should be shown where your exported file is - and that's just what I can think of off the top of my head.
I need to think some more about the architecture of all this
Regarding import: I think new question types should be allowed to extend the GIFT format with their own syntax. For example we could specify that anything between <question type="newtype"> and </question> would be text that would be parsed by import code that is supplied by the new questiontype "newtype". Exactly the same extension would then also work for the XML format.
I hear what you are saying - my immediate (possibly prejudiced) reaction is that approach throws away alot of the reasons for using XML. That is, there is considerable 'built-in' support for it.
I'm going to be radical and suggest that GIFT should be something we want to deprecate. The existing code for gift import could translate to XML and then we import XML into the actual database. Even better the GIFT GUI that just appeared could be modified to output in XML.
For the many other formats that are some form of XML anyway (and I suspect most new formats are likely to also be XML) it is 'simply' a matter of an XSLT transformation. Point is we only have one 'real' import and export format - other formats modify that. If XSLT support is an issue, it would be possible for moodle.org to provide an online conversion service. The XSLT transforms would be available and need not be done in Moodle/PHP at all - so other products could very easily incorporate Moodle XML format. OK, I am trying to turn the world on its head and advocate a Moodle (xml based) quiz format that others can easily integrate. Before anybody asks - I still think that qti is too complex for the purpose at the moment. It all seems more elegant to me and has some interesting possibilities going forward.
But I do take your point - more thinking
I'm going to be radical and suggest that GIFT should be something we want to deprecate. The existing code for gift import could translate to XML and then we import XML into the actual database. Even better the GIFT GUI that just appeared could be modified to output in XML.
For the many other formats that are some form of XML anyway (and I suspect most new formats are likely to also be XML) it is 'simply' a matter of an XSLT transformation. Point is we only have one 'real' import and export format - other formats modify that. If XSLT support is an issue, it would be possible for moodle.org to provide an online conversion service. The XSLT transforms would be available and need not be done in Moodle/PHP at all - so other products could very easily incorporate Moodle XML format. OK, I am trying to turn the world on its head and advocate a Moodle (xml based) quiz format that others can easily integrate. Before anybody asks - I still think that qti is too complex for the purpose at the moment. It all seems more elegant to me and has some interesting possibilities going forward.
But I do take your point - more thinking
Text format import and XML format imports have two completely different purposes. Text format is there for importing question sources created by humans and XML format is there for importing computer generated sources (usually exported by other software tools).
The Moodle's GIFT format is useful and popular because it is easy for humans to write it using nothing more complicated than a text editor. Why are you proposing to deprecate it?
The Moodle's GIFT format is useful and popular because it is easy for humans to write it using nothing more complicated than a text editor. Why are you proposing to deprecate it?
Oh sorry - I haven't gone mad. I just didn't explain very well.
I think that the *native* format for import and export should be "Moodle XML Format", which will be loosely based on an image of the database format. To get to or from any other format there will be some tools to do that. Clearly in many cases (eg GIFT) that operation would be based on the existing import/export code.
I must admit that I haven't fully thought this through - but the toolbox would be 'loosely' coupled to Moodle. As far as a user is concerned they would still be able to upload GIFT straight into Moodle (or copy and paste into an edit window perhaps). In the background this would be converted to XML and then the XML imported.
The advantages that I see are...
1. The Moodle quiz code is simplified - a lot.
2. We are advocating a native xml format for moodle quizes.
3. The quiz tools project is written as a 'pluggable' side project. It can be used on it's own and stuff like the XSLT transforms are available for Java (or whatever) developers.
4. You can convert an import format to an export format - GIFT to QTI in one step!
5. The xml format will be self-extending. If a new question type is added it will automagically work in XML. This will still need the toolbox extending (if required - often not the case), but as that will be uncoupled from Moodle it will be easier to make the additions.
I think that the *native* format for import and export should be "Moodle XML Format", which will be loosely based on an image of the database format. To get to or from any other format there will be some tools to do that. Clearly in many cases (eg GIFT) that operation would be based on the existing import/export code.
I must admit that I haven't fully thought this through - but the toolbox would be 'loosely' coupled to Moodle. As far as a user is concerned they would still be able to upload GIFT straight into Moodle (or copy and paste into an edit window perhaps). In the background this would be converted to XML and then the XML imported.
The advantages that I see are...
1. The Moodle quiz code is simplified - a lot.
2. We are advocating a native xml format for moodle quizes.
3. The quiz tools project is written as a 'pluggable' side project. It can be used on it's own and stuff like the XSLT transforms are available for Java (or whatever) developers.
4. You can convert an import format to an export format - GIFT to QTI in one step!
5. The xml format will be self-extending. If a new question type is added it will automagically work in XML. This will still need the toolbox extending (if required - often not the case), but as that will be uncoupled from Moodle it will be easier to make the additions.
QTI may be complex for you (and me!) but it's still the best standard there is so let's not give up that easily! Someone will surely come along with the right combination of programming skillz and hard-headededness to tackle QTI! Surely, somewhere in the world someone is working on a library for it right now. 
I like the idea of factoring out the format support into each question type. Though it'd be nice to have complete support for the standard question types first just using the existing structure.
I like the idea of factoring out the format support into each question type. Though it'd be nice to have complete support for the standard question types first just using the existing structure.
The Ilias LMS apparently has QTI import and export working (as of version 3.2). Since it's GPL'd and PHP it's probably worth a look, though I think knowing German would help too.
Dutch publishers do not want to support Moodle as long as it does not support QTI (2.0) They seriously invest in QTI.
Gift is nice, but NOT a broadly supported format: only used by Moodlers.
Dutch schools and Universities are confronted with the raising prices for BB, but consider migration to other platforms that do support QTI.
It won't go away will it
Perhaps this really *is* where we should concentrate some effort then. I will have a look at David's suggestion and see if something can be gleaned from that.
My problem has always been the difficulty in building a test framework for QTI. I don't have any particular fear of actually coding the stuff, and we now have QTI export. I need to be able to generate the stuff and test the output from Moodle. I've never really found anything. Of course the pragmatic neccessity is for it to be able to function with some of the projects and products that *do* exist at the moment (questionmark springs to mind, for example).
None of this reduces the usefulness of GIFT format of course - however, a GIFT <=> QTI converter would, in the long run, surely be a more useful tool in its own right?
Mmmm.....
Perhaps this really *is* where we should concentrate some effort then. I will have a look at David's suggestion and see if something can be gleaned from that.
My problem has always been the difficulty in building a test framework for QTI. I don't have any particular fear of actually coding the stuff, and we now have QTI export. I need to be able to generate the stuff and test the output from Moodle. I've never really found anything. Of course the pragmatic neccessity is for it to be able to function with some of the projects and products that *do* exist at the moment (questionmark springs to mind, for example).
None of this reduces the usefulness of GIFT format of course - however, a GIFT <=> QTI converter would, in the long run, surely be a more useful tool in its own right?
Mmmm.....
Yes - and on reflection, in the spirit of being sensible and doing things one step at a time. A concerted clean up of the existing code, adding the obviously missing stuff, and some thoughtfull refactoring is would be an excellent start.