Re: political strategy for MathML

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 "&leftarrow;" 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