From: <juanrgonzaleza@canonicalscience.com>

Date: Fri, 19 May 2006 07:00:41 -0700 (PDT)

Message-ID: <3452.217.124.69.229.1148047241.squirrel@webmail.canonicalscience.com>

To: <www-math@w3.org>

Cc: <maths@mathsonly.com>, <m.kohlhase@iu-bremen.de>, <R.W.Kaye@bham.ac.uk>

Date: Fri, 19 May 2006 07:00:41 -0700 (PDT)

Message-ID: <3452.217.124.69.229.1148047241.squirrel@webmail.canonicalscience.com>

To: <www-math@w3.org>

Cc: <maths@mathsonly.com>, <m.kohlhase@iu-bremen.de>, <R.W.Kaye@bham.ac.uk>

Charles Lyons wrote: > > When I was working on a content MathML processor, it made sense to > require that only the <minus /> be permitted, and that all numbers be > positive. This meant that such things as -(-1) could easily be > simplified by recognising the presence of two <minus /> elements > (which could then simply be removed from the DOM and disregarded). > Of course, an input parser can easily work with <cn>-1</cn> be > recognising the - sign and turning it into <minus /> then > <cn>1</cn> internally. Yes, there are several reasons which I prefer usage of minus on a positive number: Unification of encoding (-b) vs (-1), the fact that -(-1) cannot be encoded as <cn>- -1</cn> not as <cn>-<cn>-1</cn></cn> and then I prefer a nested apply. I also am inspired in certain FRANZLISP formal structures where (-1 79) is different from (- 1 79). However, note there is not ambiguity on MathML due to tokenization. > We had the same problem with complex numbers using the <cn> and <sep /> > elements, and eventually decided just to use integers/decimals in <cn> > and use <imaginaryi /> and <plus /> where necessary. This was more > flexible in the long run and allowed for pure imaginary numbers with no > parsing problems... I dislike using <sep /> anyway as its semantics > depend on the type of number being parsed and aren't 'obvious' from > the outset. Completely agree, I dislike the <sep/> content model. What is more, I am not using a real number model like <cn>1.2345</cn> because formal reasons on CanonML and because that kind of content MathML encoding is mixing presentation and content. It is assuming that presentation "." *is* the decimal sign. A future IUPAC report prepared by the Physical Chemistry Division (I accessed to a draft version of recommendation) already recognizes usage of comma and highlights that ISO 31-0 (1992) recommends comma. In Spain, one writes 3,1416 instead of 3.1416. Michael Kohlhase wrote: > > Interesting that you should ask just now, I have been stumbling over the > same thing a couple of days ago. The difference becomes interesting when > you try to do presentation with bracket elision. > > The general idea is that when we have > > <apply> > <or> > <apply><and><ci>a</ci><ci>b</ci></apply> > <apply><and><ci>c</ci><ci>d</ci></apply> > </apply> > > which should give a /\ b \/ c /\ d since /\ binds more strongly than \/. In a markup language based in canonical expressions you would use brackets for the infix version [[a /\ b] \/ [c /\ d]] whereas you could translate it to a full RPN version in computational algorithm for improving efficiency a b /\ c d /\ \/ Richard Kaye wrote: > > This issue is perhaps peripheral to the original question, > but it is interesting enough. I came across an identical > problem this morning, when I was writing a quick and dirty > stylesheet to convert XHTML+p-MathML into > plain old HTML I suppose that you refer to HTML 4.x because HTML 5 is more modern than XHTML 1.x. > that could just about be readable by people > without the right browser. (Basically, the only thing > helpful in HTML is <sub> and <sup>.) I had to > translate mfrac's as ((numerator)/(denominator)) > and have ended up with many places where there > are too many brackets. HTML 4.x is more useful than that! Code as next <span class="f"> <span class="n">numerator</span> <span class="d">numerator </span> </span> can be used in a HTML document and fractions rendered via CSS in browsers without MathML support. In fact, main difficulty with George (XML-MAIDEN) is not limitation of XML or HTML but lack of solid implementations of CSS 2.1 in today browsers. For example, fractions are broken if you try to see articles in XML-MAIDEN site with Firefox 1.0, because a bug with inline blocks. The bug is scheduled to be fixed in a next version of Firefox and you will see it correctly. See the sample in pdf for an illustration of the power of George technique. He can see more math with Opera (or any other compliant CSS 2.1 rendering engine) i can see with a Firefox with specific native support for p-MathML. However, George is working in a new CSS approach and developing a CSS cross browser stylesheet that would work very well (not perfect) for today Safari, MSIE, Opera, Firefox, and others. See, for example, some days ago update on experimental CSS technique for Firefox using special mozilla extensions: [http://geocities.com/chavchan/exp/moz-frac.xml] Of course, once browser developers correct bugs with CSS 2.1, all browsers will be able to render complex mathematical formulae without specific p-MathML support, as Opera is already able to do today. Situation would be better with future Math module in CSS 3. Any information on future CSS math module MathML folks? What properties will be introduced? Juan R. Center for CANONICAL |SCIENCE)Received on Friday, 19 May 2006 14:01:08 GMT

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