Index: openacs-4/packages/assessment/www/doc/sequencing.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/assessment/www/doc/sequencing.html,v diff -u -r1.1 -r1.2 --- openacs-4/packages/assessment/www/doc/sequencing.html 13 Jun 2004 23:20:44 -0000 1.1 +++ openacs-4/packages/assessment/www/doc/sequencing.html 28 Jul 2004 10:35:57 -0000 1.2 @@ -170,41 +170,65 @@
  • Item-checks (as_item_checks) define 1..n ordered evaluations of a user's response to a single Item. These can occur either via client-side Javascript when the user moves focus from the -Item, or server-side once the entire html form comes back. +Item, or server-side once the entire html form comes back. They are +associated (related) to as_items.

    The goal is to have a flexible, expressive grammar for these -checks to support arbitrary types of checks, which will include both -input validation ("Is the user's number within bounds?"; "Is that a -properly formatted phone number?") as well as grading ("How many points -out of the Item's total should this response get?"). The implementation -details remain somewhat uncertain, but the general approach seems -sound: define groups of checks, run through the ordered hierarchy -calling a tcl/sql callback proc that performs a comparison operation, -and then evaluate the results and implement some consequence -(navigation, etc).

    -

    Item Checks thus will have these attributes:

    +checks to support arbitrary types of checks, which will be input +validation ("Is the user's number within bounds?"; "Is that a +properly formatted phone number?"). One notion on check_sql. Instead of +using comparators we store the whole SQL command that makes up this +check with a predefined variable "value" that contains the response of +the user to the item the item_check is related to. If we want to make +sure the value is between 0 and 1 we store "0 < :value < 1" with +the check. Once an item is submitted, the system looks up the related +checks for this item and replaces in each of them ":value" with the +actual response.
    +

    +

    Item Checks thus will have these attributes:

    • -
  • Inter-item-checks (as_inter_item_checks) are -similar to Item-Checks but operate pairwise over multiple Items. These -are server-side checks though conceivably it may be possible to spin -out Javascript that could perform these client-side; this will -definitely be tricky though. Attributes include: +
  • Inter-Item-checks (as_inter_item_checks) are +similar to Item-Checks but operate over multiple Items. They are server +sided checks that are associated with as_sections defining if a section +should be displayed or with as_items, defining if an item should be +displayed.
    +
    +The goal is to have a way of telling if a section shall be displayed or +not depending on the section-checks. This way you could say that you +only display this section if the response to item(1234) "Color of your +eye" was "blue" and the response to item(4231) "Color of your hair" was +"red". Sadly we can't use such an easy way of checking the ":value" as +we do with item_checks, as we do not know which item this refers to. +Instead we store the item_id like this ":item_1234". This way the +check_sql would look like ":item_1234 == 'blue' AND :item_4231 == +'red'". Additionally other variables might be defined by the API at a +later +stage,  e.g. ":current_percentage", which would be replaced by the +current percentage value (aka score) that subject had in the test so +far. It might be interesting to pass these variables along in the API, +this remains to be seen when actually implementing the system.