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

Dear W3C HTML-Math Working Group,

 Thank you for making your specification
"Mathematical Markup Language" (10-Jul-1997) available on the web at
"http://www.w3.org/TR/WD-math/".

 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.

Further discussion on each point follows.


ITEM 1: Excessive complexity.

Simple problems should have simple solutions.  The current specification
completely fails to do this.
There is no reason that an expression like
LateX's "(x+2)^2" must require 18 low-level operations in an HTML Math system.
Simply reading the MML version should be enough evidence that there's
something terribly wrong with the specification (as previously documented
in the mailing list):
<MSUP>
  <MROW>
    <MF>(</MF>
      <MROW>
        <MI>x</MI>
        <MO>+</MO>
        <MN>2</MN>
      </MROW>
    <MF>)</MF>
  </MROW>
  <MN>2</MN>
</MSUP>

It is true that tools could be used to partially
overcome this problem, but this is evidence of a problem, not a solution.
Tools are not always available, especially at first.
Besides, why require people to develop tools unnecessarily?
It'd be better to simplify the specification than to patch it
up afterwards with some tools.

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.
This complexity is a serious problem for tool writers; I write tools
that generate HTML, and using this system I'd have to build a complicated
tool to generate trivial expressions.
It's true that processing infix operations requires some parsing,
but this is a well-solved problem domain taught in all universities.
I'm sure Netscape and Microsoft can find somebody who knows how to parse.

This excessive complexity is also at odds and incompatible with all other
mathematical systems that have preceded it.  All other math systems
have a simple and relatively similar method for expressing the most
common operations.  Why must this group develop an approach at odds
with all other math systems?  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!

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.

If "Extended-MML" or some system like it is accepted as a "shorthand", then
this specification should be rewritten to show use of this shorthard first
as the _primary_ method of interacting with MathML. Later on in the
specification you can expose the low-level operations that users may
find occasionally necessary later.



ITEM 2: Downward compatibility.

Much as the vendors would like you to believe, not everyone buys and
installs the latest version of a browser when it ships.
Netscape 1.0 still hits a web site I maintain, as do lynx and Mosaic.
Requiring "the latest" browser immediately shrinks the potential market
and utility of web sites.

This is particularly a problem for students, who are likely to be the
recipients of MathML-marked-up HTML.  Students can't always afford to get later
versions, or later versions may not be available for their machines
(e.g. Amigas).  Blind students in particular will probably be using lynx, and
it's not clear that lynx will build in MathML support any time soon.

A lack of downward compatibility will reduce the acceptance of any Math
markup language.  A "critical mass" is needed for acceptance; until most
clients can read marked-up text, few authors will use the markups.
But if there's no content using the markups, there will be less interest
in adding that capability to the client.

This is hinted at in 1.3.2, but not solved.

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.

This issue is related to issue #1.  If the markup language were human-readable
to begin with, many common expressions would be readable without any
support at all.

Thank you for your time.

--- David A. Wheeler
    dwheeler@ida.org


Note: These views are my own and do not necessarily represent the views of
      my organization (IDA).



-- 

--- David A. Wheeler
    dwheeler@ida.org

Received on Friday, 15 August 1997 17:00:22 UTC