- From: David Wheeler <wheeler@ida.org>
- Date: Fri, 15 Aug 1997 17:02:04 -0400
- To: ion@math.ams.org, rminer@geom.umn.edu
- Cc: www-math@w3.org
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