W3C home > Mailing lists > Public > www-math@w3.org > March 2006

Re: Technical reasons for some options taken on design of MathML

From: <juanrgonzaleza@canonicalscience.com>
Date: Fri, 31 Mar 2006 06:14:45 -0800 (PST)
Message-ID: <3123.217.124.69.221.1143814485.squirrel@webmail.canonicalscience.com>
To: <www-math@w3.org>

> Paul Libbrecht wrote:
>
> juanrgonzaleza@canonicalscience.com wrote:
> > For example,
> > - what is the argument to use some like
> > <apply><divide/><ci>A</ci><cn>2</cn></apply> instead of shorter
> > <divide><ci>A</ci><cn>2</cn></divide> ?
> >
> To be able to speak about the "divide" operation ??
> The same has been done in OpenMath btw.

I do not understand. I also can speak about the divide operation/function
with something like

<divide><ci>A</ci><cn>2</cn></divide>

In fact, I can write a XSLT that transform above tree. An illustrative
XSLT could be

<xsl:template match="divide">
	<apply>
		<divide/>
		<apply-templates/>
</apply>
</xsl:template>

<xsl:template match="ci">
	<apply-templates/>
</xsl:template>

If you can obtain MathML from the other (other ==> mathML) This may
indicate that MathML contains the same information than first syntax of
above.

Maybe there is one special reason both MathML and OpenMath follows that
way, then it would be good to know that.

> > - What is the reason for
> > <apply><plus/><cn>5</cn><cn>8</cn></apply>
> > instead of calculator-like
> > <apply><cn>5</cn><plus/><cn>8</cn></apply> ?
> >
> That'd be a bad-thing how would you consider, if the second was true,
> the following:
>    <apply><cn>5</cn><cn>5</cn><plus/><cn>8</cn></apply> ?
> ????
> You definitely need the operation to be at head!

No! Mathematica, Maple, almost any programming language, my
hand-calculator, etc. do not need the operation at the head. Your

<apply><cn>5</cn><cn>5</cn><plus/><cn>8</cn></apply>

is incorrect. It may be

<apply><cn>5</cn><plus/><cn>5</cn><plus/><cn>8</cn></apply>

The only theoretical advantage of prefix notation is the easy to apply the
same operator to a group of arguments. In practice, this is a weak
advantage and reason that almost all of computer packages, calculators,
etc. do not use prefix notation. In fact LISP is often critized by
programmers due to its use of (+ 5 5 8) instead of Maple, C, Java, etc. (5
+ 5 + 8).

It is more, why to use prefix notation instead of postfix as in Forth-like
calculators? 5 5 8 +

It is more I was informed that initially the specification for Content
MathML was

<expr><mi>a</mi><times/><mi>x</mi><plus/><mi>b</mi></expr>

Next the tag <expr> ==> <apply> and <mi> ==> <ci> for content

Next, it was chosen a Lispy prefix syntax but it would be good to know
reason for that technical design. What is more, an alternative syntax to
MathML

<apply><plus/><apply><times/><ci>a</ci><ci>x</ci></apply><ci>b</ci></apply>

could be

<plus><times><ci>a</ci><ci>x</ci></times><ci>b</ci></plus>

What is the advantage of former, if any?

> > - What is the reason for
> > <msup>base <mrow>index1 index2</mrow></msup>
> > instead of base<sup>index1 index2</sup> of SGML/HTML/XHTML/CSS
> > or the base^{index1 index2} of TeX systems ?
> >
> I think Mikko answered this well... you know how high you can put your
> exponent...

Sorry to say this but Mikko was not correct, see my reply to him.


> Note that msup and mfrac, just to name two, are elements that have a
> fixed number of arguments... and that has saved me hours of work! They
> are the only elements that can be checked for arity at display time. My
> generated MathML-p did contain several times expressions such as:
>   <mfrac><cn>1<cn/><mo>+</mo><mi>2</mi><mi>y</mi></mfrac>
> Which are just impossible to parse (where is the denominator?)...
> Fortunately, Mozilla prints a bold "invalid markup" which I can catch
> quickly instead of trying to guess something as have been doing many
> HTML parsers.

I can see your point, with a fixed number of arguments, something like

<msup><mi>a</mi><mi>b</mi><mi>c</mi></msup>

is clearly wrong. But correctness of markup does not help you to discern

<msup><mrow><mi>a</mi></mrow><mi>b</mi><mi>c</mi></msup>

from

<msup><mrow><mi>a</mi><mi>b</mi></mrow><mi>c</mi></msup>

Both are correct, but maybe only the second is you were trying to type.

However note visual difference between

<row>a</row><sup>b c</sup>

from

<sup><row>a b</row>c</sup>

Moreover, in a personal discussion, George Chavchanidze has pointed to me
redundant constructions found in real-life mathml documents. He offered me
some examples. One was

<msup><mrow/><mn>2</mn></msup>

I have try this in Mozilla and the document is both validated and rendered!

It is not difficult to see that above sample could be the outcome of some
incorrect automatic translator or software from some SGML/HTML construct
or maybe the outcome of some parser from LateX to MathML.

I have seen self-proclaimed semantic XHTML+MathML generators coding
authors or dates as headings of third level! I have also detected
incorrect outputs in a number of available tools for the generation of
MathML.

I agree with George that the technical design of the MathML language is
rather fragile.

It appears that due to the failure to offer direct input of the
mathematical code in the MathML specification, we will see a future
Internet containing mathematical documents very similar to that ugly
non-clean HTML generated by inefficient tools as MS Word. In fact, I am
seeing that.

I simply fail to understand the advantages of introducing the base into
the script markup.

Furthermore, what is -according to MathML- the markup for

Over
     sup
Base
     sub

under

?


> earlier, you wrote:
> > Unfortunately, the w3c MathML specification does not explain to readers
> > the reasons for the several options taken by its authors.
> >
> I think the spec is already quite complete as is... and it is good to
> ask these questions... the mailing-list is archived and also scanned by
> people that have questions such as these ones and they often get answered!
>
> Keep asking!
>
> paul
>

Juan R.

Center for CANONICAL |SCIENCE)
Received on Friday, 31 March 2006 14:14:59 GMT

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