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>

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
*