Overview of the System

Overview of the Implementation

This overview assumes familiarity with the terminology of Object Oriented programming. It is intended to introduce the readers to the design principles of the system, and often oversimplifies for purposes of clarity. Please refer to other sections for a more in-depth analysis.

Our system is written in a completely object-oriented fashion. Forms and queries are all objects, and thus are internally represented. Forms have instructions (both generic and media-specific- see below) queries and response functions.

Instructions are format strings- that is they can contain variables (such as a server name). These variables can be evlauted at compile-time or at run-time. For example, this allows for the definition of email forms that can run seamlessly on multiple servers. Instructions could read:

 Please fill-out this form and return it

with the blanked parts filled out appropriately a run-time.

Instructions can be generic (that is, they will be written on the email version of the form as well as the HTML and other versions of the form) or they can be media-specific. The above example would be media-specific, and it's HTML equivalent would be:

 Submit the form  Revert to initial values

Response functions are arbitrary LISP functions that take as arguments a list of tags and responses and a stream through which they can send something back to the client if needed. They are executed when a response to the form they belong to is successfully processed by the server.

A form has a list of queries. Every query has a set of instructions (parallel to that of a form), a type and, sometimes, a response function.

The type associated with a query is called a presentation type. They determine what kind of answer is expected from the user. Examples of types are integer, multiple-choice, date and state-keyword. Types have parameters, such as upper bounds and lower bounds, list of choices, etc. Every presentation type has two generic functions associated with it:

An illustrative example of a presentation function would that of the multiple-choice type. In email, the type (multiple-choice ("Chocolate" "Vanilla" "Other" "NA")) would be rendered as:
Please pick one of the following:

  A.  Chocolate
  B.  Vanilla
  C.  Other
  D.  NA

Valid answers: a letter between A and D.
While in HTML, it would output HTML code which would look the usual way:

In turn the accept function will ensure that the answer is really A, B, C, or D. Obviously, in more advanced form interaction environment (such as the Web's) some of the validation is done through the interface. With email, and for much more advanced presentation types, accept functions running on the servers side are useful. Among the more advanced type features that are supported or are in the process of becoming so: cross-choices coherence rules, completion on partial answers, etc.

Some queries have response functions. This stems from the distinction between forms and atomic forms. Forms have queries which can be answered independently of each other, in which case the queries themselves have response functions. Atomic forms, on the other hand, expect all queries to be filled out, answering only a few of the queries would be meaningless- surveys are a type of atomic forms.

Finally, an important feature of the system is its organization by what we call command interfaces. Command interfaces are essentially namespaces (or packages), in which forms and queries are defined. Each command interface has a library of uniquely named forms and another library of uniquely named queries. While designing a form within a command interface, a user can choose queries for his or her form. This system of sharing queries across forms can help increase productivity in authoring because some queries (such as "What is you email address?") tend to occur in many different forms.