[om] Re: [om-a] critique of OpenMath

David Carlisle davidc at nag.co.uk
Thu Jan 18 16:22:52 CET 2001

[changed cc list to om@ from om at announce]

> In fact Dan Zwillinger, in re-typesetting Gradshteyn & Rhyzik encoded stuff like
> zfunction(\sin, x).  Two sets of macros would allow either translation
> to TeX or to some computer algebra system  (to the extent possible).

So this is, in OpenMath parlance, defining a Content Dictionary.
Ie a fixed set of function names with some defined semantics.
It happens to use TeX syntax rather than the XML syntax normally
associated with Content Dictionaries, but that is really a small

> (he prefaced each macro with "z" to try to avoid name conflicts)

Fine for a one off project, but such mechanisms don't scale too well.
If you wanted to do the same thing but allow different people to
contribute different macro sets in a coordinated fashion, then you would
be moving from writing a single Content Dictionary to defining the 
OpenMath project.

> Actually, without hints from the source, it is hard to make breaks except
> in situations you are quite familiar with.

In a TeX document the author knows (or thinks he knows) the current page
width. In a document that's designed to be multi purpose (passsed to a
CA system, rendered on screen in an unknown font in a window that may
change size at any time) then it isn't at all clear that such hints are
at all desirable. It is true that it is currently hard (for general
documents and even more so of Mathematics) to get the same quality
from a TeX source that is machine generated from XML as it is from
a hand written TeX document. However things are improving, and it wasn't
so long ago that people said that printing presses would never catch on
as you got better quality from a scribe. For production work (to make a
paper book for example) it may currently be necessary to "hand tweak"
the generated TeX, but such tweaks should be there, in the final print
form for a known media, not in the MathML (or OpenMath).

> Say a commutative diagram, for arguments' sake.  I think the
> MathML renderer can't possibly do all that by itself.

MathML doesn't do Commutative Diagrams at all.
You could do them in SVG. You could lay them out by hand (and as for
text that may currently be the best way, although difficult if you
don't know how much space you've got)  But automated tools for laying
out graphs seem to be getting better and it may already be feasible just
to specify the logical graph structure of your commutative diagram and
let an automated tool render that into however much space it has.

> Such a person could use a CD, but it would not be official.
So nothing is hidden. Most (currently, all) CDs may not be approved
it doesn't stop them being used in the interim.
The Society could set up a web form that offered an "instant approval"
system rather than the proposed review system, but what would be the
point in that? 

> which turn out to be a non-existent page.
These things happen in an imperfect world. It doesn't mean that there is
a conspiracy of secrecy, which was what you appeared to imply.

> As for approval, it seems that anyone using the software 
> written at INRIA for any commercial purpose may be subjected
> to some unknown fee imposed by the authors.

It's their softare they have chosen to make it available under a
"non-commercial" licence. Commercial users need to contact them first.
So, it's not GPL, but it is not that unusual a licence is it?

> yes only if the new language is demonstrably able to solve problems that
> cannot be solved by (say)
> Mathematica's prefix form
> Lisp s-expressions
> Java RMI
> Corba
> MathML
> TeX

You could of course specify the OpenMath trees using s-expressions or
TeX or MathML etc, but that misses the point of OpenMath which is
to have a mechanism for recording the symbols used in the expression.
If we switched the concrete syntax to lisp then as far as I can see,
nothing in the OpenMath project would really need to change (except of
course some software which would need to parse/write lisp rather than
XML) The point of OpenMath is not the "language" if by that you mean a
particular XML vocabulary. It is the collection of symbol definitions
and  combinations of those symbols.

You could specify an OpenMath encoding in the \ and {} syntax that
people think of as TeX.  You can also get TeX to read OpenMath in the <
and > syntax that people think of as XML. But if you do either, or both,
of these, then OpenMath is still solving problemns that are not
addressed by TeX (or the other systems that you list).


This message has been checked for all known viruses by Star Internet delivered
through the MessageLabs Virus Control Centre. For further information visit
om at openmath.org  -  general discussion on OpenMath
Post public announcements to om-announce at openmath.org
Automatic list maintenance software at majordomo at openmath.org
Mail om-owner at openmath.org for assistance with any problems

More information about the Om mailing list