- From: William F. Hammond <hammond@csc.albany.edu>
- Date: Fri, 29 Oct 1999 08:41:50 -0400 (EDT)
- To: www-math@w3.org

David Carlisle <davidc@nag.co.uk> writes: > there are other ways, for example you can imagine a system with an > embedded math input interface not unlike webeq's that let you type > inline tex and have it insert mathml in to the document. > > Or for users of Widows WP systems like MSWord, they can use mathtype4 > today and get mathml expressions into their documents. Maybe it's not quite as bleak as I suggested. > Probably more people today can render MathMl on the machines on their > desks than could render dvi files a couple of years after TeX came out. > Have faith, things change rapidly:-) Well, you have to understand how things are over here in the colonies. :-) > > I would need to add symbol declarations, something that is not at all > > like present LaTeX, > I don't understand. If you want to access a right arrow then somewhere > you have to have a symbol definition, be it a \mathchardef for TeX or an > <!ENTITY declaration for XML, don't you? I am certainly not talking about cdata entities when I say "symbol". I should have said "math symbol declarations". (Aside: doesn't an XML processor see "←" as a unicode number? You want the processor to do a reverse lookup on that thing when parsing it in a math zone? Well, it could be declared with "\mathsym" as described below. But I would prefer "<leftarrow/>" if it is to have a default parsable meaning as a math symbol.) After all, mathematicians understand how to interpret TeX math expressions, and before that they knew how to interpret hand-written expressions, once they know what the symbols mean since they understand the traditional notation for forming expressions. In traditional mathematical writing the meaning of symbols is explained in non-formulaic prose. Adding a math symbol declaration to a TeX-like document relieves automatic processors of the need to digest the prose explanation, which the human reader still will want. It is trivial for a CAS to spin out various representations, including LaTeX and MathML, of its mathematical expressions since it is in possession of semantic information about them. Converting from LaTeX's math mode to MathML is not possible. (One can guess.) A human reader can interpret LaTeX's math mode because the human reader is in possession information about the components of the expression and there is logic to the centuries of tradition for typeset or handwritten notation that is used to build symbols into expressions. Whereas the inline LaTeX $fx$ -- equivalent in LaTeX to $f x$ -- is not subject to translation to MathML out of context, it could become so with appropriate math symbol declarations such as \mathsym{f}{f}{(real, real)} \mathsym{x}{x}{real} where the first arg is the string name of a declared math symbol, the second arg is its formatting for markup, i.e., can contain markup, and the third arg is a string for the type. Ideally, if different players are to be able to use such a system, the type should be something under a public formal relative typing system with a defined calculus that provides rules for computing the type of a finite expression from its component symbols when each of those symbols is typed. My use of "relative" indicates that such a system does not actually encode semantic information, but rather provides rules for determing the type of an expression from the types of its constituents without having knowledge of the meaning of any type. It falls upon a document author to resolve type ambiguities when forming expressions. (I would not make symbol declaration a requirement for journal articles, but it should be there for those who want it.) This could then be an avenue for enabling a CAS to import a net served XML journal article served in an XML application for authors such as TEI+{succinct TeX-like math} with an appropriate reference to an XSL stylesheet. Done this way, the CAS would have to swallow the whole document, look up the symbol declarations and compute the type of any expression to be imported. A lot of work, and, really, not so cool. A better avenue would be to have a net-served down-translation from the authoring language to XHTML+MathML which every CAS is expected to know something about. (The publisher may perceive a free copy in this format as less threatening to the sale of bound paper.) Such down-translation should be possible for a math expression where each symbol constituent has been declared and typed with \mathsym as described above under a suitable public typing system. The down-translator yells at the author if the document's type logic does not work. It does not make sense unless the current major CAS folk interested in this avenue work together to provide us with the public typing system. With luck somebody will have some code libraries to share so that the down translations from various XML applications -- which will not be a CAS responsibility -- have hope of getting things right. After all, who looks bad in the naive user's eye of a formula that is typeset nicely and transparent to the user gets processed incorrectly because the underlying down-translation to MathML, which the user does not see, is wrong. This is cooperation. Everybody wins. The opposite world is where a user puts a proprietary notebook format online for others who are only able to use it if they have the product that generated the notebook. (This, in fact, has been trivially possible since the early 90's dawn of HTTP/1.0 using the mimetype "application/x-CAS-foo" or even a registered mimetype.) The hard part will not be getting this going correctly. It will be getting authors to provide math symbol declarations. -- Bill

Received on Friday, 29 October 1999 08:41:54 UTC