After quite some talking with various people inside and outside the community I updated the Design pages to incorporate design decisions. I will not retouch these specifications again, unless being asked to for good reasons :).
Fundamental decision has been made, which makes it's way through the whole design specification.
- As many attributes of an object (item, choice, section, assessment, ...) will make it into a general cr_item_type.
- Additional, type dependend attributes will be added by linking an object of the type with the original object.
What does this mean. Let's take an item for example (The item description is up at
https://openacs.org/projects/openacs/packages/assessment/design/as_items.).
- An item stores it's core information in an object of the as_item type. Core information would be name, description, adp snippet.
- Depending on what kind (e.g. multiple choice) of item it is, a second object will be created of the type associated with the kind (e.g. as_item_multiple_choice type). A relationship between both objects will be created. If we copy an item, we might as well create a new relationship between the copied question object and the type object associated with the original object.
- Depending on how we want to display (let's say textarea) the item, a new object of the as_display_textarea type will be created and associated with the item. For faster processing reasons we are going to put the widget type and display_code (for HTML) as attributes with the as_item object itself, but this can be overruled by the associated display_type.
The specification for the display functionality can be found at
https://openacs.org/projects/openacs/packages/assessment/design/display.
The types of items have already been identified at https://openacs.org/projects/openacs/packages/assessment/requirements/item_types. To my knowledge these should cover all use cases, but I'm more than happy to incorporate more.
Internationalization of content will be done in line with the specs/ideas posted by Joel
What does this mean for assessment:
- We have all information ready to work on the item repository, store the information in the database and display it on one page.
- The current import and data model written by Eduardo and Alvaro should be amended to make use of the description (and the CR).
- Nearly all functionality asked for in the use cases is reflected in the specifications (somewhere), we need to map this now to the use cases.
- We need feedback if the specifications are understandable enough for the user wanting to evaluate if assessment is of good use (https://openacs.org/projects/openacs/packages/assessment/requirements/) and if not, state why and how we can improve.
- Feedback by developers on the design specifications would also be highly appreciated, especially by the e-lane folks who already went ahead and wrote the QTI import.
