From: Stan Devitt <jsdevitt@maplesoft.com>

Date: Thu, 7 May 1998 09:59:37 -0400

Message-ID: <DFBA4AED6924D111959A0060975EA7B4511A64@romulus.maplesoft.on.ca>

To: "'mathas@maths.usyd.edu.au'" <mathas@maths.usyd.edu.au>, www-math@w3.org, mailing@maths.usyd.edu.au, list@maths.usyd.edu.au

Date: Thu, 7 May 1998 09:59:37 -0400

Message-ID: <DFBA4AED6924D111959A0060975EA7B4511A64@romulus.maplesoft.on.ca>

To: "'mathas@maths.usyd.edu.au'" <mathas@maths.usyd.edu.au>, www-math@w3.org, mailing@maths.usyd.edu.au, list@maths.usyd.edu.au

Dear Andrew: In your note "Goals verses syntax in MathML" you raise several points which I understand roughly as: 1. A desire for simple hand-editable formulae 2. Concern over the size of resuling encoding. 3. A desire to get by with something closer to a simple extension to HTML including font changes such as triggered by <EM>, perhaps introducing shortcuts such as ^ for superscripts, etc. Let me attempt to address each of these. My remarks are from my personal point of view and do not necessarily represent the position of the working group. Other members of the group will no doubt speak up when necessary. (1) Initial attempts in the MathML working group to deal with an input syntax seriously considered all the issues you raise. Some of the alternatives considered and rejected for (1) included: - TeX / LaTeX - ISO-12083 and extensions - simple linearizations of formulae such as (x + y)^2 / z; - Programming language syntaxes such as for FORTAN, C, Maple or Mathematica - Inventing a new "simple input language." - internal formats of existing Math Editors. To be be acceptable, (remember we were seeking to provide the infrastructure for the next generation of publishing tools) a solution needed to support professional quality publication (as rich as TeX) and archival of machine readable mathematical data for purposes of automatic searching and computation. The latter was based on the mathematical meaning of the expressions, not their appearance. Anything less than the above, and effectively we are reduced to using pictures of formulae and that we already have. The pictures are not really editable. Nor is it possible to reliably deduce semantics. None of the considered syntaxes came even close. Programming input languages had one narrow semantic interpretation and were generally weak on presentation. Any presentation encoding less than TeX did not provide the kind of professional quality presentation needed by publishers. At the same time, TeX was fully presentation based and did not provide any mechanism for capturing semantics. For example did $D^2\,y$ represent a double application of a differential operator to the function y or was it a simple monomial? As an interim position on simple input syntax, perhaps the only position consistent with ensuring that adequate information could actually archived on Web pages, we have been translating to and from MathML from many of the above formats. Each of the companies involved has found this fairly easy to do and it has meant that everyone can work with the simple input syntaxes and tools they are already comfortable with. Developing yet another syntax for mathematical expressions is never to be taken lightly, and that is why we are moving with extreme caution. Should it emphasise semantics or appearance? Should it be based on syntax familiar to a large number of users or should it be new? If the author wrote someting in a particular style, did they do so to achieve a certain visual effect, or did they want to specify particular semantics? Can we provide the infrastructure for the author to "say what they mean?" (They can still choose not to.) It seems clear that no one "simple" input syntax meets all needs, and even though any particular user may not be interested in all aspects of math representation at this time, growth of electronic publishing cannot occur without the infrastructure, and that very growth may have the same user clamoring for different information just a few months from now. (2) On the issue of band width, while the notation is verbose, it also compresses extremely well. This issue of transmission is common to a wide range of emerging applications including such things as CML, a chemical markup language, and XML in general. It was a conscious decision to focus on a proper specification and factor out this issue. (3) During the development of MathML we looked long and hard at simple extensions to HTML. In particular, interim reports based in part on ISO-12083 and the use of SGML conventions to provide short-cuts were developed and rejected. With regard to compatibility with HTML, etc. there is currently an enormous amount of activity in W3C dealing with the integration of XML (of which MathML is an sample application) into the HTML environment. This includes work on Cascading Style Sheets which have enormous potential as a mechanism for setting default attribute values (fonts?) etc. in the manner you have proposed. The role of the style sheet mechanism must be clarified but it is potentially ideal for setting (or overriding) default presentation and semantic information. I hope my explanation helps, and by all means feel free to ask for further clarification. Stan Devitt, Ph.D. Senior Math developer Waterloo Maple Inc. > -----Original Message----- > From: mathas@maths.usyd.edu.au [SMTP:mathas@maths.usyd.edu.au] > Sent: Wednesday, May 06, 1998 11:57 PM > To: www-math@w3.org; mailing@maths.usyd.edu.au; > list@maths.usyd.edu.au > Subject: Goals verses syntax in MathML > > Dear All: > > I have just been reading about the proposed MathML solution to > displaying mathematics on the web. I would like to echo the > comments of others that the proposed solution is absurdly > complicated. [Stan Devitt] ... stuff deleted .Received on Thursday, 7 May 1998 10:03:45 GMT

*
This archive was generated by hypermail 2.2.0+W3C-0.50
: Saturday, 20 February 2010 06:12:47 GMT
*