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

Dear Juan,

I have to say that it'll be too late for me to answer you completely 
today but I don't see what are the interest of such comments.

I also believe you mix up operator-based syntax (where precedence is 
defined) with content-syntax which is standardized... and I see no 
reason to mix them!

If you want a comfortable syntax for input of formulae, any XML is 
horrible whatsoever... use extensible parsers and converters as there 
are many!
(I tend to love QMath for extensibility, http://www.matracas.org/, there 
are many others).

paul

juanrgonzaleza@canonicalscience.com wrote:
>> 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:38:47 UTC