From: <juanrgonzaleza@canonicalscience.com>

Date: Mon, 19 Jun 2006 08:34:11 -0700 (PDT)

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

Date: Mon, 19 Jun 2006 08:34:11 -0700 (PDT)

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

**What is the goal?** If I understand James and Ian?s statements correctly, the play is that either one provides a perfect markup in less than 12 tags can offer us dinamical pages with TeX quality for liquid layouts and generic web fonts (even TeX cannot), was implemented in browsers with zero changes in the parser =:-0 and was accepted and broadly used by community before was even introduced in the draft of the spec OR one would implement THE alternative. The alternative is p-MathML 2 markup which is DOM unfriendly, CSS and XSL-FO unfriendly, and even XML or HTML unfriendly: <tag1><tag2>ccc</tag2></tag1> and <tag2>ccc</tag2> are not equivalent in XML or HTML but can be in MathML. The alternative introduces dozens of presentational markup elements violating basic web guidelines. The alternative is incomplete and needs of another several thousand of dozens of tags (c-MathML 2 and OpenMath extensions) specially if accesibility is a target (and it is by law in some countries). The alternative needs of additional DOM and style specific extensions since available CSS, XSL-FO, and DOM do not fit (really MathML does not fit in the rest of the web). The alternative is spreading ugly, structurally incorrect, and inaccesible code on the web. Take the case of Distler Mussings blog, after several attempts and a recent correction based in my "review" now it changed the way {ds}^2 is encoded, but still the structure and the visual rendering are wrong: e.g. ds is rendered in italic with small space between d and s whereas the same ds -but in {ds}^2- is rendered without space and in roman font. Yes, the visual rendering of the alternative is, in many ocasions, poor: certain nested fractions, matrices, and array structures, tensors, some subsup constructs, predefined MathML entities. Moreover, due to difficulties for authoring MathML code one can see incorrect renderings on many MathML code generated by usual MathML tools: HERMES, IteX, ORCCA translator, MathCast, ASCIIMath, and others. Some of equations contained in canonicalscience site were corrected by hand after being generated by popular MathML tools. I would do more fine-tuning of some equations still remaining incorrect rendering in current version of the site but I decided stop that nonsense since MathML is not way. I will update lot of examples (extracted from academic sites where good visual quality is one of first requisites) in canonical science today blog in near future. The alternative (the spec) does not specify how one would encode something so simple as \dot{q} and there was some intense debate about that topic this year in the w3c MathML list with three main postures: all-Unicode (minoritary), all-MathML (only Bruce), Unicode+MathML (mayoritary and probably introduced in next MathML spec). Yes, you read ok, after 10 years the first w3c attempt to encode mathematics on the web, we were discussing how a trivial \dot{q} would be encoded just some months ago!!! Mathematica 5.2 visual rendering of the MathML code generated by IteX for \dot{q} was poor that if hand-drawing by a 5 years babe!!! See MathML list for details, links, and fragments of code. The alternative needs of so many efforts on the browsers side that browsers are ignoring it and even the own w3c editor/browser has a partial support of p-MathML (c-MathML is ignored by Amaya). The alternative (using more tags) is not able to encode script structures could be encoded in ISO-12083 markup model (developed before). Moreover, the number of tags increases exponentially in MathML for each new script structures were added in future specs. because of the base interference problem of MathML incorrect design. The alternative adds both new parsing and WS rules to those of XML and HTML. The alternative is formally deficient and it is not rare to see tools exploiting holes in the w3c specification for generating tricky (nonsense) code: e.g. <msup><mrow/><mn>37</mn></msup><mi>X</mi> when the correct code is <mmultiscripts><mi>X</mi><mprescripts/><mn>37</mn><none/></mmultiscripts>. Moreover, Ian?s specific proposal introduces still more additional (backward incompatible) parsing rules. And the specific problems with Gecko MathML support: non-incremental rendering... I do not see requirements imposed to mathematical markup are being imposed to MathML not in others parts of the spec: calendars, canvas. Is not the "gauge" a bit unbalanced? **Usage of weak arguments agains MathML alternative** In this list I have heard. - CSS approach cannot compete with MathML rendering quality But I can provide examples of contrary! In fact, I will do in canonical science today including snapshots of different formulae obtained from real sites. - People ask for MathML in HTML5. People in this list asked for HTML-Math proposal and I think that almost all participants in this list expressed some disapointment with MathML. - People is not using MathML because cannot be used in HTML. That is, lack of interest in MathML is mainly traced to XHTML trouble. False. People can use MathML directly in HTML pages since years (see recent link) [http://www1.chapman.edu/~jipsen/mathml/asciimath.html] Still authors are rejecting MathML. - MathML is not popular in browsers because small target False, same people (e.g. Microsoft) rejecting native support in browsers is supporting MathML offline. The big problem with MathML is that is browsers unfriendly and reason is rejected whereas developers focus on implementation of other funcionalities in browsers. - Implementation of HTML-Math is very expensive. False again, with HTML-MathML being many times more expensive since spec is more complex, ugly, redundant, and needs of lot of additional code, tests, and extensions for correctly work: CSS extensions, DOM extensions, Parser extensions... - The CSS approach would prove is working before being implemented. Where it has been proven that MathML is working on the next basic points: i) structural markup. ii) visual rendering, iii) accesibility? Please provide real code from the web rather than theroretical analisys. - We, Ian and James, are providing an alternative This sound me, cianure or guillotine? **Political issues again?** Since main emphasis of Ian and James discussion is not in technical issues (I do not know of a single technical contributions to the math draft) but in political and sociological issues. I am obligated to ask: Is there hidden political points below this dicussion? I ask because there was further politicial issues on MathML specification "However, as I have observed again and again during the decade I've devoted myself to the issues of electronic mathematical communication, the principle challenges are not technical, but political. MathML is not the way it is exclusively because of language design considerations -- it is the way it is because it was the politically feasible compromise between the many conflicting interests of the consortium members that had a stake is standardizing a markup for math notation." Robert Miner (w3c MathML 2.0 editor) "But as a standards organization, W3C cannot and should not favor the interests of one particular interest group over others. This is particularly true, as I explained in an earlier message, since W3C is directly accountable to it dues-paying member organizations, and only indirectly accountable to individuals with no official standing, such as yourself." Robert Miner (w3c MathML 2.0 editor) Last part to be read like more dollars (or euros) imply more control of final specs. If reply is affirmative, some of us would waste our time in more productive goals. Juan R. Center for CANONICAL |SCIENCE)Received on Monday, 19 June 2006 08:34:11 UTC

*
This archive was generated by hypermail 2.3.1
: Monday, 13 April 2015 23:08:27 UTC
*