Forum OpenACS Q&A: Response to Survey Package Expansion Proposal
Point 4. Survey_grading_total_score is a IMS raw score. The concept of "cut scores" is addressed by the survey_point_translation table... if i understand the IMS document correctly... cut scores basically means translate a raw point total to something non-numeric... and this is what survey_point_translation does... it can accomidate as many levels of cuts as you want (well it is limited by the number of possible raw score integers in the survey).
Point 5. I am fine with changing the name "grading_comments" to "scoring_feedback"... i would be inclined not to use the general comments package. Although comments will be made on the various acs_objects created by the survey package
survey survey_section survey_question (we wouldn't need to use this for feedback) survey_response (this would work with general comments)they won't be 'general comments' on the first two of these objects because these comments will only pertain to one participant and thus must be bound not only to an object (as all general comments), but also be bound to a single participant (which general comments are not). I need to change the data model i proposed a bit to take this into account it should be ready and posted on the website mentioned at the end of this post by noon PST on oct 24th (thanks for pointing this out). My father, who is a professor, has said he would it would very important to have a "canned response" system, where the prof can pre-define a number of answers and select the one he/she wants easily... instead of having to type a unique entry (this is where the table survey_grading_comments table - which will be renamed survey_scoring_feedback table - comes in, and where general comments would certainly not work).
Point 6, i think grading_points (which i have now renamed to scoring_points) does in fact replace the IMS Answer Key, but as i said before it is more versatile - and it keeps the data model as simple as possible (which having a seperate table for one type of scoring and a different table for another type of scoring would not do). I do not think it should be called "answer_key" because I am hoping that survey is generic enough to work with things like personality tests, or similar (in this case scoring_points would seem like a much better column name, because answer_key would at least to me seem confusing if there were no "right answer" for a non-academic scored survey where the various multiple choice answers provide differing points - none of which is "better" than the other).
point 7. I have no preference for calling it branching or sequencing - this is something Dave suggested so he would have to comment on it.
I have posted the page i wrote up with the naming convention changes i have adapted at a website i still have from when i was in school... i don't know when they will disable my account, but for now it will work: http://www.ocf.berkeley.edu/~geddert/openacs/survey/