- We need to maintain the "state" of an Assessment throughout its lifetime. This "state" consists of the wording/composition/etc of each Item and Section as it was during a subject's data collection event. This "state" is defined by the revisions of the Items and Sections and the rows in the mapping tables that associate them. Maintenance of this "state" is most important when creating reports/data extracts/etc of collected subject data.
- The semantics of when a new "state" exists is something that ultimately needs to be declared by the domain experts who set up the Assessment -- ie the admin users with edit privileges. However, since there can be more than one such admin user, we need a communication mechanism that alerts all other admin users whenever a new "state" is being constructed (ie when someone revises an Item, adds an Item, etc etc) and allows the other admin users to adopt the changes, or not.
- This means that there can be multiple "states" of the entire Assessment hierarchy that are "live" simulaneously. So we need mechanisms to make sure that each subject who comes to do an Assessment gets the right one.
If we make each of the main components (as_assessments, as_items, as_item_choices) all CR entities (extend cr_items and cr_revisions) and then we procedurally maintain the appropriate rows in the mapping tables (which don't need to be acs_objects like acs_rels but could be -- though do we win anything by making them such?), and build in appropriate use of notifications, warnings etc into the editing UIs, then will we accomplish this? Seems so, though until we start to work out the details, I think it will be hard to know for sure.
Storing the adp snippets with the revisions seems like mostly an efficiency convenience, eh? It will make spitting out the Assessment to a user who needs to take it faster, but we don't want to rely on the snippet for any definition of what the nature of the revision is.