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

David Carlisle wrote:
>
> > <apply><sqrt/>Content</apply>
> >
> > over something like
> >
> > <SQRT>content</SQRT>
>
> there are advantages when you look at extensions.
> <apply><csymbol>foobar</csymbol><cn>1</cn></apply>
> you know immediately that that is a foobar symbol applied to 1 and
> furthermore you do not need to extend the dtd to make that extension.
> If every function had a special content model then the dtd is a lot less
> flexible. (OpenMath takes a more extreme line than mathml here, some
> content mathml do use special forms, but the general design aims are the
> same.

Then an argument for choosing the apply construct may be DTD design.

However, still the DTD may contain *specific* information about the full
content model for each operation.

For example, some like

<apply><times/><cn>1</cn><cn>1</cn><cn>1</cn><cn>1</cn></apply>

is permitted but something like

<apply><divide/><cn>1</cn><cn>1</cn><cn>1</cn><cn>1</cn></apply>

is not.

Therefore, it appears that advantages of something like

<apply><csymbol>foobar</csymbol><cn>1</cn></apply>

over this

<csymbol><cs>foobar</cs><cn>1</cn></csymbol>

or maybe

<foobar><cn>1</cn></foobar>

or even

<csymbol><apply/><co>foobar</co><cn>1</cn></csymbol>

is not so great. In fact, I cannot see realistic practical advantages of
something as

<apply><tag1/>content1</apply>

<apply><tag2/>content2</apply>

over

<tag1>content1</tag1>

<tag2>content2</tag2>

I would prefer DTDs for something like

<h1>This is my favourite heading</h1>

<p>This is a paragraph</p>

over

<appply><h1/><cnt>This is my favourite heading</cnt></appply>

<appply><p/><cnt>This is a paragraph</cnt></appply>

by some reasons: input, reading, unification with XHTML, etc.

> > I was not referring to the use of TeX syntax (which is not XML and
> therefore omitted in MathML). I was referring to the fact that *base* is
> outside of the “sup” tag in both SGML/HTML and TeX. That is, in TeX one
> > does not write things as

> the fact that TeX does not explictly mark the base of ^ expresions is a
> real problem when converting TeX to anything else. You have to parse
> back to find the base (and with TeX syntax that can never be more than a
> guess). superscript is almost always denoting a 2 argument function
> such as power(..,..), and it is far more natural to treat both those
arguments
> in a consistent way, making them both children.

Yes, I agree about LaTeX. It is a very erratic an informal way to coding
something and reason was also rejected in Maple, Mathematica, etc.

However, I think that there is not realistic improvement of something as

<msup>base index</msup>

over SGML/HTML

base<sup>index</sup>

specially when tagging the base using the <subform> construct.

I expressed here examples where the double argument nature for <msup> is
violated via using trick (which indicates that specification is
"fragile").

I also am aware to read in that way a structure like

Over
     sup
Base
     sub
under

fits in the MathML syntax <tag>argument1 argument2</tag>.


> > if you have something like
> >
> > <msup><mi>a</mi><mi>b</mi><mi>c</mi><mi>d</mi></msup>
> >
> > what mean "((ab)^c)d" or "a(b^c)d" or something else? Also MathML syntax
> > is ambiguous. This is reason that I carefully used an mrow example in my
> > previous post
>
> your example is a syntax error, so mathml would assign no meaning to it
> and it would be rejected by a mathml syste,. msup may only have two
> child elements and your example ha 4.

Still poor than that. The example I wrote does not correspond to the math
I was supposed to describe!

Sorry by the inconvenience!

I mean that "((ab)^c)d" could be explicitly tagged as

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

or (à la SGML)

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

whereas "a(b^c)d" is

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

or (à la SGML)

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

or even

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


> > Are there technical/conceptual advantages introducing the base into the
> > script node or simply a matter of taste?
>
> Many advantages. It makes the function application clearer, and it makes
> it much easier to correctly position the superscrpt based on the size of
> the base.
>
> David

Perhaps it takes the function application a bit clearer (I cannot see that
from a XSLT programmer view) but adding confusion with SGML/HTML/LaTeX way
to do things.

It is a bit strange to use something as base<sup>over</sup> in XHTML 1.1
but <msup>base over</msup> in math. Therefore that advantage turn into
disadvantage when transformations to/from MathML are needed. Since MathML
is NOT designed for direct input, we need an input syntax (e.g. LaTeX) or
an edition tool for almost any realistic mathematical piece, and those use
{base}^{index}.

I think that MathML syntax is NOT much easier to correctly position the
superscript based on the size of the base, since

<msup>base over</msup>

is formally equivalent to

<row>base</row><sup>over</sup> of SGML.

the browser layer is not more complex in the second case.

It is more, I repeat again, what is the MathML representation for the
structure

Over
     sup
Base
     sub
under

?


Juan R.

Center for CANONICAL |SCIENCE)

Received on Friday, 31 March 2006 16:35:55 UTC