Figure 1 illustrates the application architecture for Zed, comprising the standalone application edition, run as a separate program, and the component edition, an ActiveX control hosted in an ActiveX container. Both editions use a common core framework for editing MathML elements, built on the rendering support for MathML presentation elements provided by techexplorer. In either edition, standard file operations can be used to open, load, save, and close files from the filesystem, and standard edit operations such as cut-and-paste can be used to interact with the clipboard. Drag-and-drop operations are supported for moving expressions from one place to another in the editor, or between different editor instances, or to open files from the filesystem.

Figure 1:  The Zed Application Architecture

The application edition of the editor is implemented as a standalone executable by subclassing the top-level Zed classes to create a standard Windows MDI application. This thin subclassing layer connects frame menus, toolbars, and multiple child windows to the core editing support. Porting the editor to other operating-system platforms could be easily accomplished by retargeting this layer for the additional platforms.

The component edition of the editor is implemented as an ActiveX control by subclassing the top-level Zed classes to support the interfaces expected of an ActiveX control. Incorporating the core technology into another component framework could be easily accomplished by duplicating this thin subclassing layer to target a different model for component extensions, whether IE behaviors, Netscape-style plugins, Adobe Acrobat extensions, or other types of addins for multimedia content authoring environments.

The component edition defines a collection of custom methods and events for use from the container. These methods and events allow Zed to operate within a browser, word processor, presentation viewer, or other container to support computationally interesting interfaces for mathematical applications. There are custom methods for accessing the MathML markup for the current expression, either to get the markup as a string or to replace the expression by parsing a new string. Specific subexpressions of the current expression can be accessed using the id attribute to identify the desired expression. Analogous methods allow access to the internal Lisp-like expression format used by the editor, for those who prefer parentheses to angle brackets. Both the content and presentation markup can be accessed in these ways, allowing the editor to parse both content and presentation as input, and to convert from content to presentation.

Zed allows a high degree of customization of many aspects of the behavior of the mathematical elements and operators it supports. Six general categories of operator configuration information can be customized: layout formats, named templates, dynamic menus, palettes, traversal order, and other properties. The component edition provides custom methods for getting, setting, or adding to any of these six configuration sets and for loading and saving configuration files to the filesystem. These methods can be used by application developers to supply custom layout formats for mathematical operators, to define custom menus and palettes for their applications, to alter the default bindings for many of the keyboard accelerators used by the editor, or to supply editing behavior for anonymous function symbols.

The custom events provided by Zed allow script writers to synchronize actions with the completion of loading the component, with any modification to the current expression, or with a user-initiated action to submit the current expression for some further computation.

Figure 2 illustrates the core editing architecture for Zed, comprising the generic document and view classes that implement the balance of the editing operations, using the MathML support provided by techexplorer.

Figure 2:  The Zed Core Editing Architecture

The Zed document is responsible for representing the internal form for the MathML instance being created by the editor, and uses the custom interfaces provided by techexplorer for MathML parsing elements, and the DOM [DOM-REC] interfaces provided by techexplorer for traversing the structures created by techexplorer. The document maintains internal expression data structures representing both the content and presentation of the MathML being edited, coordinated as described in [Dooley:98] [ZedExpr:02], and each editing operation initiated by the user incrementally updates both the content and presentation maintained by the document.

The Zed view is responsible for handling user events such as keyboard and mouse events, and menu and palette items. The view implements these operations by modifying the state of the document, updating the current state of the expression cursor as needed, then using the techexplorer interfaces to refresh the MathML presentation that techexplorer displays for the user. Mouse events in a window being displayed by techexplorer are passed to techexplorer so it can generate its own custom events containing information about where in the presentation tree the event takes place. The view maps these events back to the corresponding node in the internal content using the mappings supplied by the document representation.

The main function of the editor is creating content MathML elements, and producing a coordinated MathML presentation of those elements as described in [Dooley:98] [ZedExpr:02]. While complete support for editing MathML content elements has been implemented, as described in the following paragraphs, MathML presentation elements are used only to display the expressions, and no direct support for editing presentation MathML has been implemented. Extending the template-based framework used by the editor to encompass presentation MathML elements involves no essential difficulties, and much of this support could be provided by simply adding to the customization information described earlier. The existing editing support for content MathML elements could similarly be adjusted, and almost certainly could be incrementally improved in some areas.

The main challenge in editing MathML content expressions is in inserting and removing the desired structures, including elements, attributes, and character data. Template-based transformations have long been used for this purpose [Paracomp:88] [Smith:86], and are used in Zed as a starting point for supporting the editing of MathML elements. By assigning a symbolic name to each template transformation, a general mechanism for invoking a named template can be used to assign editing transformations to keyboard accelerators, menu items and palette buttons in a configurable way.

About 80% of the 147 MathML 2.0 content elements can be handled easily with just a few simple templates. There are 51 unary operators and elements (such as <ceiling>, <sin>, or <curl>) that Zed supports with a template that surrounds the current expression with an application of the operator. There are 18 binary operators (such as <rem>, or <implies>) that are supported with a template that surrounds the current expression with an application of the operator that provides a placeholder for the other argument. There are 32 nary operators (such as <gcd>, or <lt>) that are supported with templates like those for unary and binary operators, and with additional operations for inserting and removing child elements. There are 16 constant elements (such as <false>, or <primes>) that can be inserted by name at the current cursor position, including the <sep> element that can be inserted into <cn> elements. There are 7 qualifier elements (such as <logbase>, or <uplimit>) that can be handled internally by an appropriate positional representation with optional arguments, and so require no separate editing support. This rough taxonomy leaves 23 remaining operators and elements that require special treatment in one way or another. The next few paragraphs call out these elements (and others closely related) and describe some of the methods used to support them.

While the <apply> and <reln> elements are not qualifier elements, they can be handled positionally in the same way as qualifier elements, and so require no separate editing support. The elements <plus>, <minus>, and <times>, in addition to their behavior as nary operators, are marked with properties (such as associative) allowing the editor to support a more natural input experience than would be possible with templates alone. The templates for the elements <piecewise>, <piece>, and <otherwise> require no support other than as described above, but work together to support the input of piecewise expressions. Similarly, while no special support is required for entering <semantics>, <annotation>, and <annotation-xml> elements, a few special templates use the value of the other attribute to provide a means of overriding the default presentation for a given content element instance. The <declare> element is not supported in any meaningful way, by default, so that external applications can customize how they expect declare statements to be edited and presented.

While the <condition> element itself is supported, support for using the condition element as a qualifier element remains to be implemented, simplifying the editing requirements on a number of elements, such as <max> and <min>. The elements <limit>, <sum>, and <product> can be handled using optional positional arguments in the internal representation, allowing them to be treated much as nary operators. The linear constructor elements (<interval>, <list>, <set>, <vector>) can also be supported as nary operators. The <matrix> constructor element is supported with a special collection of operations that work to insert or remove rows or columns of the array, or to navigate to other child elements of the array. These special operations create <matrixrow> elements as necessary.

The elements <lambda>, <exists>, and <forall> require special handling in the entry of the list of bound variables associated with the element. These variables are treated as if contained in an internal child element where nary operations can be used to insert and remove additional bound variables.

The elements <int> and <diff> can be supported for the most part as nary operators with optional arguments. Finally, the support for the <partialdiff> element is the most complex of any of the MathML content elements, since the <partialdiff> element is the only element that accepts a list of bound variables, each of which is allowed to have its own separate degree. As a result, the editing support for <partialdiff> is accomplished by combining the techniques used to support nary operators (to allow for the optional total degree element, and to allow for optional degree elements on each bound variable) and the techniques used to support elements like <exists> that allow a list of bound variables. More specific details may be found in [ZedUsers:02].

Assigning a value to an attribute in Zed can be accomplished by typing Ctrl+Shift+Insert and supplying the name of the attribute, followed by the value of the attribute. This general mechanism is supplemented with named templates and menu items for setting commonly used values of commonly used attributes.

MathML entities in Zed are supported to the extent that techexplorer supports them, that is, all of the MathML 2.0 entity names and their code positions are understood, and rendered as well as the available fonts will allow. In principle, menus and palettes containing each of the over 2000 MathML named entities could be provided. In practice, special menus and palettes are defined for inserting Greek letter entities as an example of how editing support for other entities could be added. Typing Ctrl+& and supplying the name of an entity can also be used to insert a named entity.

Entering character data in a two-dimensional editor is the most significant area where template-based transformations are not the most natural approach. Zed treats the input of character data for token elements with a set of special context-sensitive operations. To a first approximation, number characters create <cn> elements and letter characters create <ci> elements, with special facilities for handling (and customizing) the treatment of juxtaposition and multiple-character identifiers, and for inserting <sep> elements inside <cn> elements. A similar approach could be implemented for entering character data for presentation token elements, and for the <annotation> element.

The IBM MathML Expression Editor is a powerful and flexible new tool for rendering and authoring MathML expressions that support a high degree of interactivity on deployment. The programming interfaces provided by Zed help to bring content-based math-aware applications to the web by providing a reusable component that can be used to provide user interaction with mathematical expressions, to accept user feedback containing mathematical information, and to produce dynamic effects involving the mathematical content. A wide range of such applications can be developed immediately using current web standards and technologies, and further advances in the web infrastructure, when combined with the capabilities of the editor, suggest tremendous possibilities for the near future.

The work described here was implemented by the author as part of the IBM MathML Expression Editor, and would not have been possible without the support of other members of the techexplorer group: Luis Alvarez, Stephen Bachop, Angel Díaz, Bill Jecusco, Richard Jenks, Mimi Jett, Thomas Ling, and Michael Reiter. In particular, work toward an early prototype for an expression editor written in Java using techexplorer by Richard Jenks and Luis Alvarez provided a great deal of insight on the issues involved in two-dimensional editing for mathematical expressions.