I'd like to get some ideas from people about what it means to maintain versions of the components in an Assessment. The reason this subject is important is that it will guide how we use the CR in the package. Humor me here while I think aloud.
First, consider that we're trying to support maximal reuse of Items, Sections and even entire Assessments while also enabling Assessment authors to modify elements as they reuse them. When an author uses an existing Item, she can use it exactly as is, modify it completely, or modify it to some degree in between. Unfortunately for us, there are no clear semantic boundaries here. If an author takes a multiple-choice Item with three options, and then adds a fourth, is this Item now a "small" version change? Or is it a fundamentally different Item? How about if the author changes the wording of the "question" but leaves all the choices the same. (We'll ignore translations to other languages for now, but that is yet another issue.)
Second, consider that the CR provides two main ways to "reuse" things. An existing cr_item can either get a new cr_revision, or it can be cloned completely into a new cr_item. From the standpoint of the CR's definitions, the first way produces two versions of one item, while the second way produces two different items. This is true even if the new cr_revision has every attribute ripped out and changed to something different from the first cr_revision, while the new cr_item is cloned without changing any its ancestor's attributes. The first case produces potentially an "evil opposite 'twin'" while the second case produces a "completely identical stranger." The point: the CR doesn't impose any semantic controls here on what constitutes a "revision" vs a new "item". The distinction is entirely left to the whims (or hopefully good judgment) of the user.
So here are the questions:
1. Is it the case that we can't and shouldn't try to be any more prescriptive in this matter than "leave it up to the user"? Should the core elements in the Assessment package be implemented as cr_items/cr_revisions and let users branch their repositories in whatever fashion they like, no matter how cluttered their respositories will get over time? This would be easiest, perhaps, but doesn't seem best to me.
2. Is the notion of a "revision" nonsensical here such that we shouldn't even use the CR? If an Item (or Section etc) is changed even a little bit, is it now a "new" entity that should stand in the repository as a sibling to its predecessor, not a child? In that case, should we merely "clone and modify" new rows in the as_items table, eg and forget about the CR?
3. Can anyone articulate a convincing rationale for when an author should make a new cr_revision "revision" instead of a new cr_item "clone"? How about this: since the "item_text" and "item_subtext" (ie "what the question is") express the meaning of the Item, if these attributes were put in the cr_item and thus made immutable, then other attributes (the number/nature of the choices to the Item, scoring, etc) could be changed.
So if the author means the same thing when revising the Item, she would make a new cr_revision and not change the wording of the question. But if she wants to change the wording of the question, then she really wants to change its meaning, so she needs to insert a new cr_item cloned off the original.
On one hand, I think that option 3 makes good sense and may serve most potential applications the best, as well as make optimal use of the CR (which is the goal within the OpenACS framework).
However, let me cite a counterexample. At some point during his research, my colleague who developed and validated the "Seattle Angina Questionnaire" (see http://www.cvoutcomes.org/demos/) added a fifth choice to one question. He didn't change the wording of the question -- just added another option for one of them. This changed the scoring of one scale and fundamentally altered the interpretation of the entire instrument. Prior clinical data scored the first way was no longer directly comparable to subsequent data. In a very real sense, the minor "revision" resulted in a semantically new assessment. So if the SAQ were being implemented via the Assessment package, how should this be handled?
Anyway, I'm keen to hear what people think about this, since whatever semantic implications we decide there are during editing any of these elements will have to be implemented via triggers or other procedural mechanisms as well as the fundamental physical modeling in the db. The better we can understand what people expect here, the more likely we are to get the package right. Thanks.
Oh yeah, and if you think that this is all a steaming pile of nonsense, please point that out, too. I may have worried myself into a deep dark hole from mulling over this too long.