[om] comments on documents

Richard Fateman fateman at cs.berkeley.edu
Fri May 17 23:23:17 CEST 2002



David Carlisle wrote:

>>Well, the MathML content is optional 
>>
> everything is optional, you don't have to use MathML at all if you don't
> want to. I have no idea in what way you mean content
> mathml is more optional than presentation mathml.


The primary purpose to which MathML is being used is for the
display of mathematics on web browsers.  My guess is that no
web browser looks at the semantic contents at all.


> 
> 
>>and never used in practice.
>>
> Maple (for example) uses content mathml when writing out expressions as
> mathml.


Have you looked at what Maple actually produces?

I typed in to Maple
3/4+x+cosh(y)+Diff(exp(x),x);
and exported it to MathML/ html.
It is about 82 lines, depending on what you count.
The really important line is
     <annotation encoding='Maple'>3/4+x+cosh(y)+Diff(exp(x),x)</annotation>
If you delete that line then the translation is
wrong  (in particular Diff is changed to diff,  and the
derivative is computed instead of displayed.)
If you delete everything except for that line (and two tag lines)
the translation is right.

My guess is that Maple uses MathML as little as possible. And that
if I were writing a Mathematica program to ImportMathMLfromMaple
I would be much better off looking for the annotation encoding='Maple"
line.

 
> 
>>If the MathML
>>content definition is by reference to the OM encoding corresponding
>>to that MathML content, and is therefore equivalent to a
>>subset of OM, then the relationship should be made crystal clear.
>>
> 
> MathML isn't _defined_ by reference to OM.


In fact it is not clear what stuff means.  I don't know if I
have found a bug or a feature that <mo> &DifferentialD </mo>
is wrong.

> But some effort has been made
> while defining the two languages to ensure that the definitions are
> compatible, and to document the equivalence, I posted a reference to a
> document on that topic to this list the other day, There are also some
> implementations of the correspondence in XSLT (which aren't complete yet
> but will be made available shortly)
> 
> 
>>so in fact the OM content in most cases gives
>>a big fat hint as to what should be displayed, by choosing
>>to transmit only one of the (infinite) number of equivalent
>>objects.
>>
> 
> There is almost no hint to presentation in the OM encoding.
> Neither the layout nor the symbols to be used.


I disagree.  See the example below.


> 
> Given your four examples, the natural encoding of
>    a
> -----
>    b
> 
> and  a/b
> 
> is the same in OM (and in my own translation to Presentation MathML, the choice
> of which form to use depends on the context not on the openmath object,
> in particular I use the first form if I'm in a display context.
> 
> Similarly a*b^(-1) and 
> 
>       -1
>     ab
> 
> would naturaly be encoded using the same openmath.


But a/b and a*b^(-1), given the usual algebraic domain are
the same.  In fact the internal form in Macsyma is roughly
(* a (^ b -1))  for all these forms.

Maybe this example will help more....

Consider this expression in Maple syntax:

exp(x)*exp(-y)+exp(x-y)+exp(x)/exp(y);

If there is a natural encoding in OM then this should come out
as  foo + foo + foo    and then there would be no way for a
presentation-only
program to translate this back into  the equivalent of the Maple
expression.
   My conclusion is that the OM content must give essential
hints on how to display the expression.  I suppose one could
put presentation tags on each of the 3 items within the semantics,
but would your XSL translator be ready for that?


> In the XSL stylesheets I have for going to presentation there are some
> fairly ad hoc rules about when to use a visible and when to use an
> invisible times, which you get depends on the values of a and b, not on
> the operator used for multiplication.


Your heuristics might not be the same as mine or those in documents
I have been manipulating which use both  invisible space and \cdot
for multiplication, but with different precedence.


> 
> For example you get ab and 3b but a \times 3 and 3 \times 4, so the choice of
> presentation form for the multiplication operator depends on its
> arguments not on the operator. This logic is most certainly only encoded
> in that one particular stylesheet it is not at all part of the OM
> specification.
> 

I think that your logic and heuristics, regardless of how careful
you are, will not be what everyone wants.  Can one say, in the
MathML... "in this expression map all multiplications to \cdot for
display"? I hope so.


> 
> 
> 
>>Just that if you stated that MathML is a subset of OM
>>you would not have to distinguish them.
>>
> 
> But we didn't, so we do.
> 

Given the overlapping memberships, I view this as
almost inexplicable.


> 
>>You don't even know what OM is competing with.
>>
> 
> The fact that there are many possible methods of encoding mathematics is
> the main reason for OpenMath. It does not mean that it is competing with
> any of those systems, it is just offered as a possible common ground.


Actually, I don't even think you believe this. You must have some
justification (like OM is better, or not copyrighted, or more compact,
or more fun, or more SGML-like, or more browser-ready, or
maybe just a way to keep busy....).  Or if what you really
want to say is that OM
is the union of all other methods, then I think you could
be more direct about that, too.


> 
> 
>>It would provide a review outside the OM club.
>>
> 
> perhaps, but there are other priorities at present. The document is
> available in public so anyone is free to comment on it.


The politics of OM  and criticisms of it would
open up quite a can of worms.  I'll pass for now.

> 
> 
> 
>>It would mean that you could use the word "standard"
>>with the same technical connotation as
>>"ANSI Standard" C, Common Lisp, ...  or
>>
> 
> Yes, ANSI, being the US representative at ISO, standards have a different
> legal status. But getting anything through ISO is time consuming (even
> if successful) and as I say it isn't clearly a good use of time at present.


I am not recommending you follow this path, except that the
use of the word "standard" borders on inappropriate.


> 
> 
>>"IEEE Standard" binary floating point arithmetic ...
>>
> My understanding is that IEEE is a consortium and its standards don't
> have any different legal status than any other body do they? 


I think that it would be quite wrong to think that an OM committee
standard has equal footing with an IEEE standard.  Or that IEEE
standards are easier to develop than ISO.


> 
>RJF


--
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