Re: Math Markup is too awkward.

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