- From: <rminer@geom.umn.edu>
- Date: Fri, 25 Jul 1997 10:36:51 -0500
- To: liam@htmlhelp.com
- CC: www-math@w3.org

Dear Mr. Quinn, It remains a goal that HTML Math be simple enough to enter elementary expressions by hand. However, it is important to distinguish "MathML" from "HTML Math." MathML is one part of an HTML Math system that must meet a wide variety of goals including hand editability. MathML is only part of that system -- the bottom layer of a layered design architecture. It is important to note that the HTML Math working group charter specifies that nearly a year (from more or less now until next May) be spent on the design of a additional layers for hand entry of HTML Math that piggy-backs off of the MathML layer. There are many user communities that need a way to put math on the Web, and their goals are very different. Groups such as publishers are concerned with having a notation system that can be used to generate high quality print documents. Groups such as librarians are interested in a notation system that is sufficiently regular and simply to process that it can be indexed, searched, and ultimately translated to new formats when necessary. Many people are interested in having a notation system that can be evaluated by other software, as well as displayed. To meet all these goals requires a notation system that is fairly complex. Rather than abandon some of these other goals and opt for a solution like inlining TeX which is easy to enter by hand, we have chosen a layered design architecture. MathML is the bottom layer, designed to provide interoperability and maintainability, and to be reasonably easy to implement -- another point in which it differs from TeX. One approach we are currently considering for providing easy hand entry is the definition of extensions to MathML. Consider again the example of LaTeX: (x+2)^2 MML: <MSUP> <MROW> <MF>(</MF> <MROW> <MI>x</MI> <MO>+</MO> <MN>2</MN> </MROW> <MF>)</MF> </MROW> <MN>2</MN> </MSUP> In generic MathML, token nodes such as <MI>x</MI> must be explicitly tagged, and schema such as MROW are only permitted to contain other elements and not data. One might define an extension to generic MathML by specifying that naked data contained in elements be tokenized according to certain rules like "alpha-numeric strings should be wrapped in MI tags", and that "{ should be replaced by <MROW>" etc. By doing so, one obtains an input language that is easy to edit by hand, that sacrifices none of the power of generic MathML for those who need it, and that can be easily expanded into generic MathML by an authoring tool or renderer for interoperability or archiving. Faking the details, the preceding example might become something like: Extended-MML: {({x + 2})}^2 or possibly {(x+2)}^2 Since the extension is a superset of generic MathML, it would also be legal to write: <msup> {(x+2)} {2} </msup> This is only one of several proposals being considered. As Dave Raggett has already noted on this list, he is working on another input language layer that would be translated into MathML. Wolfram Research (makers of Mathematica) have also developed an input language suitable for use with Mathematica and MathML, and they have indicated their intention to make a tool for processing this language available this year. Several organizations including the American Mathematical Society are investigating the possibility of producing a robust LaTeX2MathML converter. The point is that none of these input layers could serve as the common target all of them can hit; MathML can. By adopting a layered design architecture, we are confident that the entirety of the HTML Math system will better serve the needs of more people than any single compromise strategy could. Robert Miner The Geometry Center Co-chair, HTML Math Working Group

Received on Friday, 25 July 1997 11:37:08 UTC