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 x2+1 or x1/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.