From: Paul Libbrecht <paul@activemath.org>

Date: Fri, 31 Mar 2006 16:38:35 +0200

Message-ID: <442D3EEB.20100@activemath.org>

To: juanrgonzaleza@canonicalscience.com

Cc: www-math@w3.org

Date: Fri, 31 Mar 2006 16:38:35 +0200

Message-ID: <442D3EEB.20100@activemath.org>

To: juanrgonzaleza@canonicalscience.com

Cc: www-math@w3.org

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

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 21:27:37 UTC
*