An Object Model for Dynamic Math
Robert Miner
Design Science, Inc.
Abstract
Creating dynamic mathematical content for the Web is difficult. To a certain extent, this is unavoidable since there is an aspect of programming inherent in authoring dynamic content which is absent in static content. However, the current situation is greatly exacerbated by the lack of a effective model for programming dynamic math content.
There are two primary drawbacks to current Web programming models for math. The first is that currently available levels of abstraction are inappropriate. Using script code to directly manipulate math expressions via the W3C DOM operates at too low a level, while using self-contained, pre-programmed applets and controls forces authors to work at too high a level in many cases. In the former case, even simple tasks are long and laborious, and in the later, there is little room for meaningful customization or reuse.
The second drawback, is that dynamic math content requires a richer collection of UI widgets than is available in HTML. Plug-ins, applets and controls can provide additional widgets. However, in the absence of a widely-shared underlying model for dynamic math programming, efforts in this direction to date have been ad hoc and under-leveraged.
Existing Models
There is no shortage of existing dynamic math object models (DMOMs) from which to choose. The LiveMath [1] and MathWright [2] are two commercial products that provide systems for authoring and displaying dynamic math in Web pages. Cinderella [3] and Geometers' Sketchpad [4] are specialized dynamic math authoring tools that can publish to the Web. In all four of these cases, however, the Web is primarily a delivery vehicle -- the interactivity is confined to the rectangle of the plug-in, applet, or control. Simulink from the MathWorks [5] offers another kind of DMOM, emphasizing visual programming, though simulations cannot be published to the Web.
Another arena in which dynamic math object models abound is mathematical Web services. Maplets, from Waterloo Maple [g] provide a client-side UI for back-end services from a MapleNet server. Similarly webMathematica, from Wolfram Research [7] provides the computation back-end for an server page model. J/Link technology provides a Java bridge for client-side UI applications. Matlab Web Server from the MathWorks [8] offers a more traditional CGI-style solution. Obviously, all of these models emphasize server-side computation.
In all of the cases mentioned so far, Web interactivity has been added as an extension to existing desktop software. However, there are also a number of dynamic math object models implicit in the many excellent dynamic math web sites created over the last five years. A few noteworthy examples, are Project LINKS [9], the ActiveMath Project [11]. There are many more. These sites provide an excellent guide to what the requirements for a dynamic math object model should be.
Another thing that existing sites with dynamic math content point out is that despite the ready availability rich DMOMs tied to specific products, what Web authors have actually usually done is roll their own. Most sites appear to use an ad hoc mix of free or nearly free standard Web object models and technologies. They just fake the math, usually with laboriously generated images, and carefully chosen applications of interactivity. So one of the goals of the object model presented here is its compatibility with standard Web development techniques, tools, and technologies, so as to take advantage of the skill and software base already available in the authoring community.
Requirements for a Dynamic Math Object Model
In coming up with requirements for a dynamic math object model tailored for the Web, we begin by consider a list common dynamic math tasks for motivation:
- Stepping a reader through an explanations
- Enabling a reader to change parameters to observe the effect
- Enabling a reader to manipulate equations to observe the effect
- Displaying typeset previews of encoded input
- Obtaining and checking answers to online test questions
Accomplishing tasks such as these involve four broad kinds of functionality:
Manipulation of math notation
- Arbitrarily modifying an equation
- Easily modifying an equation in mathematically natural ways
Operations on math expressions
- Checking two expressions for equality
- Checking an expression for a pattern match
- Evaluating and computing with expressions
- Converting expressions into other formats, e.g. an image, etc.
Working with math-aware UI widgets
- Displaying an equation in browsers without native rendering capabilities
- Allowing a reader to modify an existing equation in prescribed ways (e.g. fill in the exponent)
- Obtaining free-form equation input from a reader
- Displaying an interactive graph
Managing interaction with readers
- Arranging for expressions to respond to mouse gestures
- Arranging for expressions respond to controls
- Manipulating controls programmatically, e.g. to initialize them
In designing a dynamic math object model, then, the goal should be to make performing these four categories of tasks easy and natural within existing Web development paradigms.
A Dynamic Math Object Model Proposal
In this paper, we propose a fairly simple, Web-oriented DMOM based closely on the requirements analysis of the preceding section. The model consists of three collections of objects: Equations, EquationControls, and MathServices.
The Equation object is a essentially a wrapper for an instance of a MathML expression. The Equation object exposes interfaces for both high and low level manipulation of the math expression it represents. In particular, it exposes a standard DOM interface for arbitrarily manipulating its expression, as well as other higher-level interfaces for manipulating the expression it represents in more mathematically meaningful ways.
MathService objects perform operations on Equations. Performing meaningful computations with math expressions is typically the most challenging part of developing dynamic mathematical content. While some simple operations are appropriate for ad hoc client-side implementation, in many cases, computations either require substantial libraries of client-side code, or are best performed server-side by specialized software. MathService objects provide a layer of abstraction to that content developers have a uniform interface to both local and remote computation services. They also serve to package collections of of similar operations together in manageable units.
The EquationControl objects provide math-aware UI widgets for extending the native set of primarily text-oriented UI widgets from HTML. For example, there are ViewerControl, InputControl, and GraphControl objects. These objects host one or more Equation objects. A current Equation can be set programmatically in a control, and a current Equation object is returned when queried. They also expose interfaces for programmatic control of relevant properties and UI configuration parameters. Depending on the availability of native MathML rendering in the browser, Equations may appear directly in the DOM, but dynamic equations would typically by hosted by a EquationControl.
Finally, in the area of managing interaction with readers, no new objects are required. What is required is that the EquationControl objects implement the DOM Event interfaces, so that standard DHTML techniques for firing and handling events can be used by content developers.
A Prototype Implementation
To explore the dynamic math object model described above, we consider a prototype implementation targeting Internet Explorer 6.
In the prototype, the Equation object is a JavaScript proxy object which represents an equation displayed by either MathPlayer or the WebEQ Viewer Control. The EquationControl objects are implemented as Java applets built on the WebEQ codebase. The MathService objects are applets which use MapleNet and J/Link to connect to compute servers.
While the prototype is still in a very early stage, some conclusions about the strengths and weaknesses of this kind of implementation can already be made. One obvious limitation is lack of cross platform support and reliance on Java. By using JavaScript proxy objects, some of the cross-platform and cross-technology details can be hidden, but at the corresponding cost of needing to manage a sizeable JavaScript library along with other document resources.
A potential strength of the approach is that it lends itself to "customizable template" documents. By sticking with standard, well-know Web development techniques, many authors who are not capable of creating elaborate dynamic math content from scratch will nonetheless be able to understand and customize template documents. Even so, it seems likely that even if such an approach were fully implemented, the pre-requisite skill level for authors would remain relatively high.
Conclusion
While there are many existing dynamic math object models available in a range of contexts, none are very well-adapted to mainstream Web development techniques. By looking at existing models, as well as existing Web sites using dynamic math, a basic set of requirements for a Web-oriented DMOM is easily constructed. A relatively simple DMOM will suffice to satisfy a basic set of requirements, and a prototype implementation suggests that such an object model could probably be adequately implemented for mainstream use, cross-platform issues not withstanding.
However, even if such a model were robustly implemented, two questions arise. The first concerns achieving "critical mass" amongst readers, since the DMOM considered here is predicated on the ubiquitous availability of MathML-aware browsers, browser extensions, stylesheets, JavaScript libraries, etc. The widespread deployment of such MathML-aware runtime environments to date has been hampered by the lack of quality content, so there is a classic chicken-and-egg problem. Industry standardization might have some role to play here.
The second question that a Web-oriented DMOM proposal must face is whether there would be a viable authoring community, even if other issues could be resolved. Experience with the prototype described here suggests that a relatively high skill level would still be required of authors. Whether or not this is a crippling obstacle to the development and dissemination of dynamic math content on the Web remains to be seen.
References
[1] Live Math, http://www.livemath.com
[2] MathWright, http://www.mathwright.com
[3] Cinderella, http://www.cinderella.de/en/index.html
[4] Geomter's Sketchpad, http://www.keypress.com/sketchpad/product_info.html
[5] Simulink, http://www.mathworks.com/products/simulink/
[6] Maplets and MapleNet, http://www.maplesoft.com
[7] webMathematica and J/Link, http://www.wolfram.com
[8] Matlab Web Server, http://www.mathworks.com/products/webserver/
[9] Project LINKS, http://links.math.rpi.edu/
[10] The ActiveMath Project, http://www.activemath.org
[11] Eric Weisstein's World of Mathematics, http://mathworld.wolfram.com/