Re: MathML: Unacceptable. Way too complex and not backward-compatible

Dear Mr. Wheeler,

You recently wrote:

>  I have some very serious concerns with this specification; I believe it
>  is unacceptable in its current form.  In particular:
>  
>  1. It is absurdly and unacceptably complex.
>  
>  2. It fails to be downwardly compatible.

and in your message you elaborated your arguments for these points.

I appreciate your concern, and I thought you brought up some very
interesting issues.  However, I mostly disagree with your conclusions.
In large part, I think this is a result of a failing on the part of
the HTML-Math working group to make clear what MathML is intended for.
I will try to address your major points, and explain why I disagree.

You wrote that 

> There is no reason that an expression like LateX's "(x+2)^2" must
> require 18 low-level operations in an HTML Math system.

and that

> This excessive complexity is also at odds and incompatible with all
> other mathematical systems that have preceded it.  ... There is a
> reason that other systems (troff's, Latex's, Word Perfect's,
> Mathematica's, etc.) accept expressions similar to "x+y^2" as a
> valid expression!

However, in the case of all the software systems you mention (except
possible Word Perfect, which I don't know well) the software uses a
complicated parser to turn input like (x+y)^2 into a data structure
much like that described by the MathML encoding.  Indeed, the
presentation elements of MathML are closely patterned on the
presentation data structure in Mathematica.

The point is that in order to display or process mathematical
notation, a fairly complete and more or less explicit expression tree
is required.  All the applications you mention create one, but to
varying degrees, it is hidden.  MathML is intended to be an open,
accessible encoding at this level.

You also wrote:

> One claim is that this complexity makes it easier for tool builders.
> This claim is false; the current approach will make it HARDER for many
> builders.

I believe you were thinking mainly of authoring tools.  The HTML-Math
group has feedback from a number of people who have implemented MathML
renderers, and prototyped authoring tools, among the the W3C Amaya
browser team.  Nearly all of these people have reported that MathML
processors are fairly easy to implement.  I agree that there are some
situations, especially in authoring, in which MathML may be more
complicated than some other markup language.  But in most situations,
an application that intends to process math notation in a meaningful
way must maintain some sort of data structure on a par with the MathML
schema, and typically the translation is pretty smooth.

On the topic of complexity, you conclude:

>  Mr. Robert Miner (rminer@geom.umn.edu) wrote on "Fri, 25 Jul 1997" a message
>  describing a system called "Extended-MML" which would define a set of
>  common shorthands to permitting simpler phrasings for common operations.
>  I would strongly encourage examining such systems; indeed, I suspect that
>  the approach should be optimized for such "shorthands" with the expectation
>  that people will use the "shorthand" except in special cases, and in those
>  cases they should only need to use more complex forms in special cases.

We really do understand how important, short, human-readable input
syntaxes are.  Clearly, your particular needs aren't met by MathML and
would be met by an input syntax more like LaTeX.  We are very aware
that most people are in this category.  

Our intention has always been to provide that short, easy input
syntax, and this is exactly what Extended-MML is supposed to do.
Defining this language is the main business of the HTML-Math working
group for the coming year.  It is our expectation also that authors
would use MathML extensions as the typical method of interacting with
MathML.

The second major point you raise is downward compatibility.  You
pointed out that most people do not use the very latest versions of
software, and even if they do, there won't be native MathML software
in browsers immediately.  I agree completely, and this is a serious
problem.  You wrote:

> What is needed are a series of escape clauses.  There should be a way
> of including an "APPLET" message inside a Math message so that
> Java-enabled browsers which don't support the Math extensions can run
> a Java applet that will correctly render the Math.  For example,
> perhaps "all Math markings are enclosed in an <EXPR> expression, and
> <APPLET> tags are ignored inside an <EXPR> expression".  Or even
> better, perhaps there should be a general mechanism for invoking an
> applet if a request feature doesn't exist.

Again, I mostly agree with this.  The MathML proposal asks for a
mechanism for invoking applets and other embedded elements to render
MathML.  It also proposes ALT fallbacks for text based browsers like
Lynx.  The HTML-Math working group is also working closely with the
HTML working group on this issue for XML extensions to HTML in
general.  

I really like the idea of explicitly ignoring some selected subset
of HTML tags like <applet> which are embedded in at least some  MathML
elements, so that old browsers will fall through the MathML code and
hit the embedded HTML.   This works really well for the <applet> tag
now, and I will bring it up before the committee as a very reasonable
suggestion for MathML.

Another point you made was that if MathML was more "human readable",
i.e. more like LaTeX, fallback mechanisms would be less important.
This is certainly true, and again the answer is that this is one of
the functions Extended MathML should provide.


Yours,

Robert Miner
The Geometry Center
W3C HTML-Math WG co-chair

Received on Monday, 18 August 1997 00:09:23 UTC