The types of user input Wims can accept is limited by the http protocol. They include multiple choices (menus), numerical data (real, complex or others), text data (equations, expressions, matrices), plane coordinates (clicking on a picture). Multiple input data can be contained in one user request, via the html form protocol.

The input of geometric objects other than points is not supported by ordinary html standard. Therefore this can only be achieved by text data or by using java applets.

The capability of Wims to process user input is only limited by that of the various softwares interfaced by it. In particular, unlike many other Internet exercise systems where user answers are merely compared with stored standard answers, answers to exercises under Wims are mathematically analyzed, providing a much higher freedom for exercise design. For example we are able to create exercises whose good answers are not unique, or those accepting multi-step answers. Sophisticated error analysis mechanism can also be built into exercise modules, helping users to understand the reason of their failures.

Most exercises under Wims incorporates random parameters (numerical, functional or configurational), so that they are highly non-repetitive. They are usually also configurable by several configuration parameters, intended to teachers for setting up the level of difficulty of the exercises for their students (see Section 5).

Users through the Internet are often not very strict on syntax rules, when
they input mathematical expressions.
For this reason, a special command (*rawmath*)
is implemented in the Wims scripting language, which allows automatic
correction of common syntax ``errors'' whenever there is no ambiguity about
the intention of the user.
For example, `2x` is corrected to `2*x`,
`sint` is corrected to `sin(t)`,
`(x-1)(x+1)` is corrected to `(x-1)*(x+1)`, etc.
In ambiguous situations such as `x2+1` or `x^1/2`,
a warning message prompts the user to enter `x^2+1` or `x^(1/2)`, if he wants to say x^{2}+1 or x^{1/2}.

The algorithm of *rawmath*
is constantly improved according to the real behavior of the users shown
by log files of the server.
Without the use of this command, as much as 30% of expression inputs were
rejected due to syntax errors.
Under the current version of *rawmath*,
syntax errors are reduced to less than 5% of all expression inputs, of
which only a small fraction is attributed to `failures' of *rawmath*,
such as rarely used function names which are not recognized (for example
csc).

Wims systematically checks all user input fields for consistency of parentheses, and prompts the user for correction when unmatched parentheses are found.

Currently Wims has several approaches for this purpose.

Common mathematical symbols (such as \pi, \beta, \sqrt, \leq, \int) can be directly inserted into the text, using inline directives with a syntax similar to TeX.

The command *htmlmath*
takes an expression and renders it as best as possible, using available
html tags.
It is fast, but rendering is not very good due to limitations of html language.
2/3 can only be rendered as 2/3.
It is intended to rendering simple expressions.

Much more powerful is the command *instex*
, which takes a TeX source and compiles it to a graphics file which is inserted
in the place where the command is.
This command has mechanism to detect whether the source is constant or
dynamic.
For the former, the generated graphics file is stored in a permanent and
session-independent place, and reused for subsequent calls, in order to
gain speed.
At each subsequent call, the file time of the graphics file is compared
to that of the file containing the command, and the graphics file is renewed
if the latter is newer than the former.

If the source is dynamic (that is, if it contains a variable to be substituted),
*instex* generates a temporary graphics file stored in the session's directory,
which is never reused for subsequent calls.
This guarantees that the formatted expression will follow the changes of
the context.
In order that the browser does not reuse the graphics file stored in its
cache, a unique time stamp is appended to the address of the graphics file.

For the time being, the performance of dynamic *instex*
is not satisfactory.
Perceptible delay occurs even for one dynamic *instex*.
In fact, the mechanism of *instex*
is to transform the TeX source into a dvi file, then to a postscript file
via *dvips*, and finally to a gif file using *convert*.
The last step calls *Ghostscript*
to interpret the postscript file, and it is here where the bulk of the delay
takes place.
Performance can be greatly improved if we have a driver transforming the
dvi file directly into gif.

Wims has also a mechanism allowing the user to change the font size of TeX
related graphics (*instex*
and inline mathematical symbols), in order to make it correspond to the
font size of his browser.
This mechanism is still rudimentary, in that for registered users, the
choice of font size is not permanently stored (so that he should re-choose
the font size at each login).

The MathML standard offers an extremely interesting possibility for mathematical rendering. Wims is prepared to support this standard, but this is not yet implemented because most currently used browsers do not recognize it.

Before we reach a stage where almost all installed browsers become MathML
capable (which will not be the case before several years), the server must
have a mechanism to detect MathML capable browsers, and send MathML codes
only when this is the case.
This can eventually be done by analyzing the name and version of the browser
contained in the **HTTP_USER_AGENT**
environment variable, but the ideal solution is that in the http protocol,
there be a standard variable indicating whether the browser accepts MathML.

Once a MathML capable browser is detected, both *htmlmath*
and *instex*
can be made to output MathML code, allowing MathML support without modification
at modules' level.
What is needed here is to create routines generating MathML codes from
raw mathematical expressions and from TeX sources (planned in the development
project of Wims).

One may also create a single output command, which accepts a mathematical expression in its raw form, and automatically prepares an appropriate output (html, TeX, MathML) according to the circumstances.

We have yet to find time to implement a routine translating raw mathematical expressions into TeX source.

Another particularity of the system is the capability to output animated
graphics in a very convenient way.
The command *insplot*
accepts a raw mathematical expression, and insert a plot of the expression
at the place where the command is.
The expressions to be plotted can also include an animation parameter,
in order to make *insplot*
render animated sequences.

In a similar way, line graphics can be rendered via the command *insdraw*.

Wims has also an interface to Povray, allowing it to render ray-traced 3D graphics. See Section 3 for more details.

All these graphics insertions are dynamic. Static graphics can be inserted using ordinary html links.

The number of simultaneous accesses is limited only by the server resources. This limit varies according to the speed of the server and the network connections, as well as the nature of the modules accessed. It ranges from 2 to 3 for very intensive requests (such as animated graphics), to more than 50 for usual exercises with no intensive computation nor TeX formatted output, on a server equipped with a Pentium II-266 CPU. This indicates that with normally distributed usage, one server site powered by a reasonably fast computer can satisfy the teaching requirements for several hundred students.