An example message in XML Dormin is presented below.

<message>
   <verb>NotePropertySet</verb>

   <properties>
      <MessageType>InterfaceAction</MessageType>
      <Selection>
         <value>Instruction1_ta</value>
      </Selection>

      <Action>
         <value>UpdateTextArea</value>
      </Action>
      <Input>
         <value>TEXT</value>

      </Input>
   </properties>
</message>

As in all Dormin messages exchanged between the tool and tutor, the root element is <message>. The first child element, <verb>, is used by Lisp in tools such as CyclePad and in TDK-based tutors, but is not presently used by CTAT.

The <properties> element wraps the <MessageType> element, and a series of property-value pairs. A property-value pair is defined as a property element (e.g., Selection) and a child value element.

For a list of all message types, see the Glossary of Message Types.

Selection-Action-Input is a common notion implicit in the Dormin format. Sometimes referred to as SAI, the Selection-Action-Input triple is a way of representing a student action in three dimensions: 'Selection' refers to the instance name of an interactive widget in the interface; 'Action' refers to the action that the student took upon the widget; and 'Input' is the value that the student entered. Where an input doesn't apply (such as a Done button), the value of -1 is used.

While the notion of SAI remains constant across the various message t ypes, it is employed in slightly different ways. For example, requesting a hint corresponds with a selection of both "hint" and the instance name of the currently selected object.

A problem author will commonly define a start state by entering values in a tool's user interface. As the problem author inputs an initial problem state, each action should correlate with an InterfaceAction message that is sent to the Behavior Recorder at the time of demonstration. Each of these InterfaceAction messages will be recorded by the Behavior Recorder and later stored in a BRD file.

A typical InterfaceAction message is given below:

<message>
   <verb>NotePropertySet</verb>
   <properties>
      <MessageType>InterfaceAction</MessageType>

      <Selection>
         <value>Instruction1_ta</value>
      </Selection>
      <Action>
         <value>UpdateTextArea</value>

      </Action>
      <Input>
         <value>TEXT</value>
      </Input>
   </properties>

</message>

The InterfaceAction text is enclosed in a MessageType element. The three vectors that describe the InterfaceAction message are Selection, Action, and Input. Selection describes a unique name of the interface element that was selected. Action describes the action that was applied to the interface element. Input represents the input value that was entered by the user.

After entering problem-specific information, the tutor author will then complete the start state by selecting the Behavior Recorder menu command Graph > Create Start State. In response, the Behavior Recorder sends a message of type StartStateCreated back to the tool:

<message>
   <verb>SendNoteProperty</verb>

   <properties>
      <MessageType>StartStateCreated</MessageType>
      <StartStateName>Name-of-start-state</StartStateName>
   </properties>
</message>

Most tools, upon receiving a StartStateCreated message, should lock all interface widgets that accept start values (e.g., a text box that contains problem description text). The exception is the tool that allows for the student to modify start state values.

A tutor is often reset to a problem's start state. This occurs, for example, when loading a BRD file or selecting the start state node in the Behavior Recorder.

Resetting to the start state triggers a sequence of message events to take place:

All problem-solving attempts are communicated with the InterfaceAction message. In this basic action, the message properties are selection, action, and input. Selection is the name of the widget. Action is the action performed on the widget. Input is the value(s) entered in the widget.

In response, the Behavior Recorder will send one of the following message types:

A CorrectAction message may be accompanied by a message of type SuccessMessage.

An InCorrectAction message may be accompanied by a message of type BuggyMessage.

For details on these messages, consult the Glossary of Message Types.

When a student requests a hint, a message of type InterfaceAction should be sent. The selection vector should contain values of hint and the instance name of the currently selected object.

In response, the Behavior Recorder will send a message of type ShowHintsMessage. A sample message is shown below:

<message>
   <verb>SendNoteProperty</verb>
   <properties>

      <MessageType>ShowHintsMessage</MessageType>
      <HintsMessage>
         <value>This is the first hint.</value>
         <value>Please enter '2' in the highlighted field.</value>

      </HintsMessage>
      <Selection>
         <value>firstNumGiven</value>
      </Selection>
      <Action>

         <value>UpdateTextArea</value>
      </Action>
      <Input>
         <value>2</value>
      </Input>

   </properties>
</message>

The Done attempt, commonly accomplished by pressing a Done button, is treated like any other problem-solving attempt; in response to the InterfaceAction message, the Behavior Recorder will respond with either a CorrectAction or InCorrectAction message.

An example message for a done attempt is shown below:

<message>
   <verb>NotePropertySet</verb>

   <properties>
      <MessageType>InterfaceAction</MessageType>
      <Selection><value>done</value></Selection>
      <Action><value>ButtonPressed</value></Action>

      <Input><value>-1</value></Input>
   </properties>
</message>

Tool-tutor communication can be implemented using one of two communication models: asynchronous or synchronous communication. In asynchronous communication, the tool is always ready to accept messages from the Behavior Recorder. In synchronous communication, the tool waits for

For a tool to successfully support tutoring, it should also include:

These facilities are not required for the tool to operate with CTAT's Behavior Recorder, but they have proven to be successful in intelligent tutor implementations over the years, and are therefore recommended.

For examples of how CTAT tutors have implemented these facilities, see the Fraction Addition Example-Tracing Tutor.