Advance Information on the XTutor Toolkit

The XTutor toolkit is being developed MIT Department of Electrical Engineering and Computer Science, and scheduled to be released in summer 2005. A preliminary version of the toolkit has been used by several thousand students over the past few years in the MIT's mainstream courses in introductory software, artificial intelligence, computer architecture, and discrete mathematics.

The toolkit supports the delivery of online lectures and automated tutoring. It lets students hone their skills by answering questions and by debugging designs in an environment that encourages easy exploration and provides immediate feedback. Automated interaction interests students and saves staff from the tedium of correcting assignments. Assignments can include the kinds of fill-in and multiple choice problems common in computer tutoring programs. They can also move beyond simple questions and answers to more interesting automated interactions such as circuit design, writing programs (6.001), and proving theorems (6.034).

Some XTutor details

XTutor will be based on Twisted/Nevow, an open-source, Python-based framework for implementing web services. The XTutor team has contributed numerous bug fixes and a flexible template system for creating web pages from database information to this open-source project. The framework

• serves http/https, standard web documents
• support user extensions (coded in Python) triggered by URL or file type
• handles certificate-based or password-based authentication
• efficiently manages threads and database connections

XTutor is designed to be a turnkey system that can be easily adapted to many courses with minimal administrative overhead. It can be installed as a a wrapper around an existing course website, and adds web-based course administration tools, as well as XDocs, which provides interactive access to an XML-based content repository.

XTutor uses a lightweight database (SQLite) for logging and data-mining, and provides simple schemas for user info, document info, log entries for each user interaction with a document, including answers and other info associated associated with each interaction.

XDocs

XDocs is a collection of user-extensible interactive XML documents. Users can define new namespaces/tags and provide handlers that determine how the tags are processed when generating XHTML and checking student submissions.

Handlers are specified separately from the document itself. This approach, which differs from the usual implementation of "server pages", ensures that the content isn't intertwined with the underlying mechanism, making it much easier to reuse the content.

• There are predefined handlers to support answer types: numbers, multiple choice, etc.
• Different handlers can be specified for different contexts, e.g., rendering a question and answer as a worked example vs. part of an on-line quiz.
• When checking a response, a tag handler can access the complete document tree and history of student's answers to questions in the document, e.g., "mark this correct if all answers in this section sum to 15 and this is at most the third attempt at an answer".
• Handlers can invoke external programs for content display (e.g., creating a GIF image of a graph) or checking a response (e.g., running a circuit simulator or a proof checker).

The XDoc system also handles user submissions related to a particular xdoc. Typically the submissions are in the form of a HTTP POST generated by the browser when the user clicks a submit button. But more sophisticated client-side applets can use other submission mechanisms, such as XMLRPC, to interact with the XDoc system. The incoming responses are processed by the tag handlers and then saved in the logging database.

The XDoc system handles bookkeeping chores, such as

• user authentication (passwords or certificates can be used).
• reading the requested xdoc, dynamically loading the appropriate tag handlers, and building the document tree
• fetching the history of responses for this particular (student,document) pair from the logging database. A particular history entry is accessed by keyword and consists of a list of previous responses. The keyword is usually a unique ID associated with each response requested from the user, but might be any other annotation the handlers have made about the student's state.
• canonicalizing incoming responses
• performing the necessary processing -- generating XHTML, checking incoming responses, etc. -- by calling the appropriate method of the tag handler associated with the root node of the document tree. Each tag handler is responsible for the processing of its child nodes; typically, the appropriate method is called in the tag handler for each child and the processing traverses the document tree in a top-down left-to-right order. The handlers can refer to the user's previous responses and tailor their actions accordingly.
• updating the database after each submission

For more information