From: <rminer@geom.umn.edu>

Date: Sun, 17 Aug 1997 23:09:10 -0500

Message-Id: <199708180409.XAA22059@royden.geom.umn.edu>

To: wheeler@ida.org

CC: www-math@w3.org

Date: Sun, 17 Aug 1997 23:09:10 -0500

Message-Id: <199708180409.XAA22059@royden.geom.umn.edu>

To: wheeler@ida.org

CC: www-math@w3.org

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-chairReceived on Monday, 18 August 1997 00:09:23 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 21:27:27 UTC
*