From: <juanrgonzaleza@canonicalscience.com>

Date: Tue, 2 May 2006 08:44:12 -0700 (PDT)

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

To: <www-math@w3.org>

Date: Tue, 2 May 2006 08:44:12 -0700 (PDT)

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

To: <www-math@w3.org>

Neil Soiffer wrote: >> Are you sure that Unicode *precomposed characters* are >> just a rendering technique? > > Yes. They are defined to be equivalent to their > decomposed equivalent. Since you are very good at > looking at standards when prompted, I'll let you track > down the reference as to why they are part of Unicode. I thought that o + combining-diaeresis and ö were two different things in Unicode even when both are rendered equal. Of course, both are defined to be "canonically equivalent" via "canonical decomposition" but are not defined to be "equivalent". > Everyone is entitled to their opinion. Based on your > statements here and on your website, you have many > opinions, mostly negative, and mostly (in my opinion), > far from the main stream. I have negative opinions on I consider are bad approaches and positive opinions on I consider excellent ones (like anyone). Moreover, mainstream does not mean more correct or better. >> In my opinion ISO 12083 relies on ISO 8879 (1986) >> for Diacritical Marks > > On what is your opinion based? Did you find any text in > the mathematical section of 12083 to support that? I > didn't. No, I did not find; that is reason I said in "my opinion". It is based in the design of the DTD. > Is your logic is that because one implementation does > not implement all of MathML or implements some part > incorrectly, MathML is bad? How about looking at > support for combining characters in MathML > implementations besides FireFox -- I think you'll find > that support minimal. By your logic, combining > characters are bad. Or what about CSS support in > browsers -- definite compatibility/completeness issues. > Or maybe XHTML is failure because the leading browser > does not support. Rather than complain about Firefox's > limitations, I suggest you take a more positive approach > and contribute to the volunteer project by fixing some > of the problems. I think that this point was roughly discussed in the past. The difficulties on the implementation of MathML in browsers are due to weakness of the MathML specification. I was trained by common hype that "malign browsers developers" was stopping the spread of MathML but developers claim me that real issue is that it is very difficult or even impossible implement MathML 2.0. That is reason that w3c CSS WG "abandoned" mathematics support. I have been trained that MSIE was earlier interested in native support for MathML but at the end they prefered an "external plugin" via third parties because direct implementation of MathML in the MSIE rendering engine would be unsafe for the browser. The same about additional module on Firefox; I suspect limitations on Firefox support are due to own difficulties of the implementation of MathML. Opera browser developers like support for mathematics but explicitly rejected native support for MathML because implementation was considered unsafe. The problem is that MathML language cannot be integrated with rest of technology. The support of combining characters is minimal but it will increase. I am not seeing exponential increasing in MathML support. I am beginning to suspect many people will abandon MathML when discover its difficulties and limitations. XSL-FO was popular in some niches (book printing) in the past but now is apparently forgotten. Take my own case as example, I adopted experimental MathML support in 2005 and now abandoned support in 2006, since it does not fit my requirements and since there exists a big hole between MathML promises and that it really achieves. MathML promised good printing, searching, accessibility, content, rendering, and standardization on scientists’ communication. In practice, people translate MathML to TeX for printing (Prince’s developers attempting to develop direct support for MathML printing have need of many work, tricks, and modifications on the specification; I do not know details). I suspect that others will translate to other languages for printing. Searching is not working, and leader search engines recommending to me others ways for the journal. Even if tomorrow a specific MathML search engine is implemented, I simply do not know how search, since each document is encoded in different ways. Look example of q-dot encoded in four different ways even by the same application. Take the case of E = mc^2. I could try with E = mc2 (or E=mc^2) in Google and works (is not excellent but works). Please could you explain me that would I search if E = mc^2 is encoded in MathML (by commodity to write only half a dozen of possibilities offer us the "standard"). Accessibility of MathML code in most of cases is poor than using the old HTML + GIF + ALT. It is more, a guy writing a relativistic element of line in pure HTML is doing better than MathML code is being served in journals as Living reviews on relativity or ultra-technological blog such as that of string theorist Distler. The first guy encode (ds)^2 in an old HTML whereas MathML is being used as d(s)^2 (i.e. 2s ds). Content MathML is mainly inexistent on the web (accessibility issue again) and has problems also. I suspect many people would prefer to deal directly with more solid designs as OpenMath. Visual rendering is poor, due each author generates different presentational code for same concept. Even the same code so trivial as <mi>d<mi><mi>x<mi> is rendered as "d x" in Firefox but "dx" in IE + MathPlayer Moreover there are difficulties associated with extra mrows of usual ugly code, there is not fine-tuning, most of formulas look better (at least without zoom) using jsMath, which is based in a mixture of HTML and images, et cetera. About supposed advantages of using a standard for communications, I provided an example of MathML code generated by different tools was submitted to Mathematica 5.2 and two failed and the others rendered in different ways. Using a simple TeX \dot{q} the equation would be more "standard" and would work in any computer or tool with minimal TeX support. I can interchange a TeX document containing $\dot{q}$ with colleagues. If I received a MathML encoding of \dot{q}, which code would I wait of four ones I listed? How many different ways are being distributed in the Internet below a hype of "standardization"? Before waiting miraculous spreading of MathML or forcing adoption via publicity and advertising in conferences, papers, use it, use it, use it... I would gently suggest you take a more positive approach and redesign MathML from the bottom, eliminating all errors done in the past in the next 3.0. Then all browsers will adopt native support; accessibility will be a reality; author become happy... Please do not claim that a body as w3c cannot do backward incompatible changes because w3c has a good experience on those changes. > I disagree that support for MathML in browsers is > minimal. It can certainly be improved, but between > FireFox/Mozilla and IE+MathPlayer, 97% or more of the > users are covered and the common usage cases are > implemented. Clearly we mean different by "support", somewhat as we perceive problems in different ways. From the MathML FAQ <blockquote> MathML is XML-based. Will the browser manufacturers support XML fully? Will they support MathML natively ? Yes. Both Microsoft and Netscape have publicly declared support for the XML recommendation. Some XML support is already available for IE 4. As the browser manufacturers move toward fuller support of XML and the associated style sheet standards such as XSL that are developing, support for MathML will become more "native". </blockquote> Hum, now we observe XML support in many (all?) browsers, but I see only "native" (via external module and not passing MathML official test suite) support in Firefox/Netscape. > As for Opera's 12083 support, are you referring to XML > MAIDEN's "Experimental version of ISO 12083 processor > written in EcmaScript + DOM + CSS.". It claims it only > runs in "Opera 9TP2" and indeed, I couldn't get it to > work in the current Opera 9.00 beta. If you have seen > this work, why do you consider this superior to > ASCIIMath's MathML work that makes use of JavaScript and > MathML? I was referring that via small changes in the original ISO 12083, XML-Maiden let us render lot of math using just CSS. If MathML WG had modified the ISO 12083 for adapting it to the web instead of "reinventing the wheel" situation now would be close one wait. The changes needed in Firefox or in MSIE for supporting XML-Maiden are minimal and just needed of a better support of available CSS 2. You will not need an external plugin in MSIE. About ASCIIMath/MathML I prefer something as XML-MAIDEN 2.0 (clearly motivated by previous ISO 12083) <math> <fraction> <num>1</num> <den>n</den> </fraction> </math> over MathML <math title="1/n" xmlns="http://www.w3.org/1998/Math/MathML"> <mstyle mathcolor="red" displaystyle="true" fontfamily="serif"> <mfrac> <mn>1</mn> <mi>n</mi> </mfrac> </mstyle> </math> <math xmlns="http://www.w3.org/1998/Math/MathML"> <mstyle mathcolor="red" displaystyle="true" fontfamily="serif"> <mo></mo> </mstyle> </math> First is XML and can be fine-tuning, decorated, etc. via CSS (or FO if you prefer!) as I already do with HTML or XHTML text. In MathML, I need learn new redundant tags and models as <mstyle>, <maction>, etc. CSS does not work in my brosers for math but does for text... XML-Maiden is very easy to extend. It is trivial to add accessibility to above XML-Maiden code. I cannot do it in ASCIIMath and I am obligated to learn a new language (Content) and add <semantic> and <annotation> by hand or use a different tool. Moreover, none browser can understand content (and then for what?). Whereas today available browsers would understand accessibility of a XML-Maiden mathematical code with minimal or maybe none change. Moreover, many MathML code generated with ASCIIMath is based in trick usage; for example roman tokens are recommended to be entered as ‘H’ being outputed as <mtext>H</mtext> or the recommended hint sum{::}_(k=1)^n which offer us the MathML <math title="sum{::}_(k=1)^n" xmlns="http://www.w3.org/1998/Math/MathML"> <mstyle mathcolor="red" displaystyle="true" fontfamily="serif"> <mo>∑</mo> <mrow> <msubsup> <mrow> </mrow> <mrow> <mi>k</mi> <mo>=</mo> <mn>1</mn> </mrow> <mi>n</mi> </msubsup> </mrow> </mstyle> </math> <math xmlns="http://www.w3.org/1998/Math/MathML"> <mstyle mathcolor="red" displaystyle="true" fontfamily="serif"> <mo></mo> </mstyle> </math> If you consider that way to be a good approach to mathematics on the web then... For additional comments on ASCIIMath and why I rejected see [http://canonicalscience.blogspot.com/2006/02/choosing-notationsyntax-for-canonmath.html] > I can't speak to the reasons why Opera has not > implemented MathML. Perhaps they felt their target > audience wasn't interested in math or that support for > math was too costly for their target market (they > apparently decided full support of SVG was too costly). > They are somewhat alone in not supporting MathML. > Although Safari currently doesn't support MathML, they > would like to -- it was one of the most requested > features when they had a poll > several years ago. Except that they decided math support was needed (but not following MathML design ;-). They support natively SVG (whereas continue rejecting MathML as MSIE also did and continues doing it). They can render MathML via external processor (therefore the claim to "too costly" is again hype "how good MathML is and how bad browsers vendors and developers are" we are reading for years in many places). They rejected was native support for the ugly MathML implemented in the rendering engine. Many people does not know weakness of MathML, only know that there is a mathematical oriented markup from the w3c with lot of promises for accessibility, structure, searching, "standardization", content... Therefore, it is not difficult to understand the Safari poll results. This behavior is also seen in Opera polls. > If I remember correctly, your reasoning is based on > the fact that the W3C doesn't issue standards, just > recommendations. So HTML, XML, CSS, XSLT, ... are not > standards either (despite your site referring to XHTML > as a standard -- a double standard on what is a > standard :-). Who is the "we" you refer to? Yes, MathML is w3c recommendation not standard. ISO 12083 is international standard. HTML is also standard (ISO-HTML), etc. The site is incorrect. I obtained wrong idea of that MathML or XHTML are standard from many places. For instance in "The Importance of MathML to Mathematics Communication" sited at MathML official site I read <blockquote> Recent years, however, have witnessed a significant step forward in the form of a standardized encoding for mathematical notation called Mathematical Markup Language, or MathML. </blockquote> or </blockquote> Standard protocols and formats for exchanging structured data, such as HTTP, HTML, and XML are fundamental to the software architecture of the Web. In the case of math, MathML has become established as the standard format for math in XML, and this stands to benefit mathematical software development in a number of ways. </blockquote> Note also how I said that XML was a standard so recent as [http://canonicalscience.blogspot.com/2006/02/choosing-notationsyntax-for-canonmath.html] Now I know that w3c is not a standard body, just a consortium. Do not worry, homepage will be updated. Whereas above Canonical Science Today page will be superseded by a new focusing on math and science I am preparing since some time ago. However, I detect a kind of double standard in many w3c folks. At the one hand, the advantages of being using "standards" are popularized, but after previous standards are ignored and substituted by models, specific markups, specifications needing of further economic efforts by final users, why? > I'm surprised your are making a claim that 00A8 is > suppose to be used for diaresis. The entry for it > clearly says it is a *spacing* character, not a combining > character and the entry even says that it is roughly > equivalent of > 0020 (space) + 0308. Using Unicode's combining > characters for math almost always will result in > ambiguities between its linguistic meaning and its > mathematical meaning. Yes, big mistake from my part, sorry. Not sure but I think that I was reading 00A8 168 die isodia =dieresis in the MathML page [http://www.w3.org/TR/REC-MathML/chap6/bycodes.html] You are right at that point but I cannot agree in the rest. i) You claimed in repeated occasions that presentation MathML is designed for presentation, not for content. Then why you are now so worry that ü and ü can be ambiguous? Is not the objective of Content MathML that of disambiguating things rendering equal? ii) Take a look to Bruce Miller <mi><mo> proposal [http://lists.w3.org/Archives/Public/www-math/2006May/0004.html] iii) I will support Unicode standard before w3c recommendation because I do not see problem on ambiguity you claim and because I see more benefits: search, rendering, on and off usage, et cetera. >From Robert Miner article cited above <blockquote> Having a standard format also provides a clear direction for developing conversion and import and export capabilities in specialized math applications. A standard also encourages better, more uniform extension architectures in generic applications, which benefit add-on math components as well. Finally, and not least significantly, a standard decreases the risk of investment and increases the potential for return, which stimulates software </blockquote> > Neil Soiffer > Senior Scientist > Design Science, Inc. > neils@dessci.com > www.dessci.com > ~ Makers of Equation Editor, MathType, MathPlayer and MathFlow ~ > Juan R. Center for CANONICAL |SCIENCE)Received on Tuesday, 2 May 2006 15:44:30 UTC

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