From: <juanrgonzaleza@canonicalscience.com>

Date: Sat, 27 May 2006 10:10:42 -0700 (PDT)

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

Date: Sat, 27 May 2006 10:10:42 -0700 (PDT)

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

Henri Sivonen <hsivonen at iki.fi> wrote: > I am pretty convinced that the granularity of markup needed for math > and the verbosity of XML necessarily lead to an XML syntax for math > that is not suitable for direct human authoring. I doubt that. > However, I think it > does *not* necessarily follow that an XML syntax for math is an > inherently bad idea. I said not the contrary. I said is that specific MathML format is not good enough due to political issues. The weak design is even recognized by own MathML authors. > Math even more than schemas or vector graphics needs to have an XML > syntax, because math needs to integrate in prose on a more profound > level than e.g. replaced elements would allow. I do not agree; the current MathML is not really integrated with XHTML. A HTML syntax is sufficient for the structural part. With standard HTML <sub> and <sup> and a bit of assistance from a standard 2.1 CSS, one can render complicated scripts structures in a standard HTML browser without need for introducing the MathML soap <msub>, <mstyle>, <msup>, <msubsup>, <mmultiscripts>, <none>, <mi>, <mo>, and <mn>, the extra MathML attributes, the extra DOM, the extra styles, a different WS parser or the special namespace in your document. Similar thoughts when one decides reusing old but effective HTML <table> element instead of adding new redundant ones: <mtable>, <mtr>, and <mtd>. The true debate is on the content part, which is not solved with content MathML. >> 1) Insanely complicated and inefficient. In some cases, I have >> computed 15 >> times more bandwidth and server storage when using MathML than >> alternatives. > > gzip 1) First I would note that I was not talking of verbosity of XML end tags or similar, but of the inefficient markup model specific to MathML. Have you tried to encode E=mc2 in full parallel MathML? And what about fine parallel markup? Fine parallel markup is so complex that even the own Math WG provided an alternative code. They did not recommend gzip to users ;-). 2) It does no sense to offer people gzip archives of online documents for downloading and reading off-line! 3) Even using compression, one may unzip files before accessing to data. I cannot manipulate a file of 15MB in my computer when the *same* information could be stored in 1-3 MB. The w3c has done a big effort on providing us lightweight rational alternatives to old insane approaches. A typical example is the usage of a simple CSS external document for all your HTML documents instead of repetitive encoding of font style in each paragraph of each document. MathML just break this tendency providing one of most ultraverbose and redundant encodings I have seen in my life. Another example. I can write <p>This is an <i>important</i> text</p> in presentational HTML. Rationale is simple but effective, text is roman by default and when text is italic you markup with <i>. The code in a MathML fashion would be typed like <mp><mr>This</mr> <mr>is</mr> <mr>an</mr> <mi>important</mi> <mr>text</mr></mp> That is, you redundantly says to computer that each token is roman with ?important? being rendered as italic. The same information but bloated. However, since presentational markup is not likely, above <i> is better encoded as <em> in HTML. Next <em> is already rendered as italics by default but I can change rendering via i) CSS in the head of document ii) external CSS is used by several documents at once iii) Special CSS rule add via style attribute 4) Still using gzip other approaches are less expensive in both disk and bandwidth. > How is MathML not compatible with the DOM? Introducing specific DOM model does implementation in browsers mainly impossible. MathML is not integrable with rest of browsers technologies as DOM, CSS, and WS model. All this generates problems and headaches to browser developers and reason of real failure to see browsers with native support of MathML. There is a lot of technical details in Opera browser developers site on why they rejected *native* MathML support. FO developers also failed to provide unification of MathML with XSL-FO. Is this way? The manifesto for HTML 5 emphasized <blockquote> Web application technologies should be based on technologies authors are familiar with, including HTML, CSS, DOM, and JavaScript. </blockquote> and <blockquote> Basic Web application features should be implementable using behaviors, scripting, and style sheets in IE6 today so that authors have a clear migration path. Any solution that cannot be used with the current high-market-share user agent without the need for binary plug-ins is highly unlikely to be successful. </blockquote> MathML does not fit in this philosophy, therefore may be abandoned. >> Well MathML is not really based in those. But we can render math using >> just HTML, and CSS, and we can use JS and DOM in the same way we use >> in >> HTML or CSS for text. Look XML-MAIDEN >> [http://www.geocities.com/csssite/index.xml] for ideas, samples, etc. > > Interesting. However, the results have the look and feel of a > afterthought math editor for a word processor rather than the look and > feel of pdfLaTeX output. The look and feel are better that with MathML. The markup is lightweight and can be easily accessed and modified via standard DOM and CSS rules. Moreover, rendering is incremental and thanks to recent advances by George many browsers can see almost all mathematics, whereas MathML support is a kind of binary logic: or you can see math (Firefox, MSIE + plug in) or you cannot. Moreover, the MAIDEN markup can be transformed to TeX for printing via TeX engines whereas better CSS-based printed engines are not ready. Do not forget that those articles are generated with a couple of simple CSS 2.1 rules *without* font metrics information (TeX cannot do that and relies on specific collection of fonts are not designed for web and in a very complex formatting engine). Fine tuning in the web can be achieved complementing the generic XML-MAIDEN stylesheet with more rules for special cases or with fine tuning CSS rules directly inserted in the document. It is not difficult to achieve TeX output quality when using font metrics. Improved rendering engines and more experience with CSS in this field would provide a better rendering quality. However due to difficulties for implementation of MathML in browsers, it will be difficult that you can obtain fine tuning of formulae someday. And, of course, it is close to impossibility that you can provide a TeX engine for the web (one of reasons TeX has failed to conquer the web). >> One of problems >> with this approach is that once new STIX fonts available I can use >> them in >> HTML, also in CSS rendering of math, but I cannot use them in firefox, >> since MathML module would be rewritten, and the full engine >> recompiled, >> obligating to users to download and install new versions of browser >> for >> new fonts!!! > > The PUA mapping is indeed a problem. If you want to see a change here, > I suggest creating an OpenType font that uses the Type 1 > outlines from the YandY version of Computer Modern and has proper > Unicode mappings. I prefer to follow usual web design guidelines providing rendering engines and technologies were independent of the fonts installed at the client side. But this does not impede implementation of specific rendering printer engines dealing with a collections of predefined fonts in specific domains. For example a library could implement a printing engine optimized with font metrics for the STIXs. CM no thanks! >> 4) The default printing of MathML is not good and people is >> returning to >> TeX for that! > > In general, Knuth was over 20 years ahead of everyone else. CSS-based > typesetters are still catching up with TeX on some things. (And the > bar is pretty high.) No. It is relatively trivial to provide TeX quality in different markups when one knows font metrics. In fact, one can see several authors providing TeX quality with SVG and even with HTML approaches when font metrics are known. However, nobody has provided TeX quality using just MathML. Only do I note the paradox that neither SVG nor HTML were designed for mathematical rendering? This low quality has obligated to people to translate MathML to TeX and next print formulae with a traditional TeX engine. The really difficult problem is to provide good typesetting quality without rely on specific fonts; Knuth has not solved this still ;-) > But yes, if you want to print math, pdfLaTeX is the best thing > around. Changing the syntax of MathML does not help in catching up. > Improving the rendering engine does. No, the problem of MathML is in its syntax and content model. Both are incompatible with the rendering engines of browsers and as previously said also publishers using XSL-FO in books and documents were unable to incorporate MathML in the rendering-print engine. HTML Math could be incorporated in a few days because it an incremental implementation. >> 5) Accessibility is very deficient > > A different syntax won't help. Implementations of accessibility tools > will. False. Alternative syntaxes for mathematics already proposed are more accessible than MathML by several technical motives. Moreover, it has been proven that current implementations of MathML in browsers are not detailed enough for that accessibility tools can work. This is reason that MathPLayer audio rendering does not deal correctly with tabular data and that generates some ambiguous readings. Ambiguous rendering are absent when one uses old GIF model + ALT. Ambiguous rendering could be eliminated if providing a new approach in the future HTML. By encouraging usage of p-MathML in HTML 5 one is generating inaccessible code. >> Moreover, the situation is still poor than that! Many sites claiming >> theoretical accessibilities (e.g. Distler blog) are serving (ds)^2 as >> <mi>d</mi><msup><mi>s</mi><mn>2</mn></msup>, i.e. 2s ds!!! > > I'm pretty sure Distler doesn't claim his math to be accessible, and > I'm pretty sure he is quite aware of the paradox that AsTeR does not > support MathML even though its author was on the WG. > > http://golem.ph.utexas.edu/~distler/blog/archives/000199.html Distler does lot of different claims. In the accessibility statement [http://golem.ph.utexas.edu/~distler/blog/accessibility.html] says ?Equations are written in MathML 2.0.? And do not explain that accessibility of their self-proclaimed ultra-advanced blog is poor that if had used old HTML + GIF + ALT model (or using PDF or even LaTeX). For instance Distler does not explain to his readers that when using ALT attribute in a GIF the image is more accessible that when using the verbose MathML code it is generating and serving on the Internet. Perfect p-MathML 2.0 code is not really accessible, but still poor, MathML code is being served by Distler is structurally invalid and based in tricks. For example, he is using <mrow> and tricky collections of <msubsup> for simulation of tensors. He does not use invisible operators introduced in MathML. He encodes prescripts as in TeX via empty groups instead using <prescript> tag. This is odd! The question is why one would encourage usage of MathML in HTML 5 when it is doing poor that old approaches! We can offer accessible math in next HTML 5. There is not such one paradox! MathML does not work. Accessibility of MathML is just a myth. >> 6) There are problems with default rendering of entities > > XML entities on the Web are b0rked. Since MathML is not human- > writable anyway, let's get rid of the entities. Curiously the problems with MathML entities are solved in other approaches. I already solve that some time ago... >> Accessible code render ugly in screen whereas >> visually correct code being inaccessible. > > "Accessible" code is just theory, right? No. >> 7) The possibility for automated searches of math continues being >> largely >> a myth. > > Many, many things related to searchability, internationalization and > accessibility are myths in the realm of semantic markup. Then this is argument for not usage of MathML in HTML 5, point. However, you just are systematically failing to understand main points here. Take the case of searches. If anyone encodes E=mc2 in HTML, I can search it with Google and works very well. But I cannot search the formula when encoded in MathML (presentation, content, or parallel). There is ?infinite? ways to encode same formulae because specification is weak and full of technical holes. I did an experience with a simple dot{q} in most popular MathML tools. Each MathML tool encoded the same TeX command in different ways. Moreover code generated by two of MathML tools failed to be rendered by Mathematica 5.2 when directly copied and pasted. I can copy \dot{q} from any TeX doc and paste it in any other TeX doc and TeX engine will work. I can copy E=mc2 from any HTML source and copy it in a HTML editor and will work. Using XML-MAIDEN or ISO 12083 inspirated approaches the encoding would be far more uniform and, therefore, ready to automated search by some engine. >> 8) Visual rendering is not incremental as in CSS. This can offer us >> problems with large documents or even with server failures. I find >> just >> curious the w3c emphasis on abandoning non incremental rendering of >> old >> HTML presentational table layout models in favour of CSS layouts, >> whereas >> forcing usage of a non incremental MathML presentational markup. Some >> mathematical documents take order of 10 minutes before rendering in >> Firefox. > > This is not a design problem with MathML. This is Mozilla bug #18333. Is _that_ bug related to the 10 minutes, to that MathML rendering is not incremental when compared to a CSS solution, or what? Moreover, you may know that the problem of the bad MathML support on Firefox (and other Gecko based browsers) is not due to the low-quality of programmers but to the explicit incompatibility of MathML with previous HTML and CSS layout models. However, I can promise you that implementation of the same mathematics in an alternative math approach could be implemented in current browsers in less than a pair of days. Again MathML does not fit with the Position Paper I cited previously. >> 10) Advantages of being using a "standard" vanish when one observes >> the >> infinite malleability of mathml code. For example people is simulating >> tensors with nested msup, msub, msubsup, and tricky mrows, instead >> using >> <multiscript> and <none/>. Then hypothetical standardization >> advantages >> are lost. > > Yeah, MathML is presentational in practice. No, because both visual rendering *and* structure of those formulae is incorrect. (Presentational MathML was also designed for structuring mathematics as you know). The problem is in the MathML design again. For instance, ISO 12083 -using less tags- was able to encode more scripts structure than MathML 2.0 can. The interesting is you would add one or two new tags to HTML for a full rendering of tensors. Since all people would use same tags, the encodings would be standardized. Moreover, you could use <sup> for both text and math. >> 12) The use of presentational markup is contrary to common sense. > > Is LaTeX contrary to common sense? Which looks better a LaTeX > printout or a Mathematica printout? You are failing to fix the point. My full message was >> 12) The use of presentational markup is contrary to common sense. I >> write <H1> in HTML and next I said one -and only once- in a CSS how the >> heading may be rendered in my doc. That CSS, when stored externally, can >> be called by billions of others HTML docs. In MathML you are forced to >> repeat presentation in each formula in each document, to use mstyle... >> >> The use of a presentational language for mathematics remember me the old >> days of the <font>, <b>, <i>, <center> tags. Little impact of MathML in >> the web remind me the failure of XSL-FO to conquer the web. Instead >> specific presentation MathML markup complemented with lot of <mstyle> >> tags I would prefer semantic or structural markup. Precisely LaTeX substituted TeX presentational markup by default stylesheets and macros with emphasis on content. You apparently misguided the point that HTML was semantic markup, after transformed in presentational markup by big developers (the nightmare of <font>) and recently retransformed again in semantic markup with presentation best done by CSS and elimination of <font> and family. Similar approach was taken in ISO 12083, with structural markup in SGML and styling via DSSSL. However MathML adds presentational tags and styling markup directly *to* the document which is contrary to common sense. Precisely also future Latex 3 is being mainly improved in the stylistic part with emphasis on copying SGML and HTML models. For example, LaTeX 3 interface will support DSSSL specifications and style-sheet concepts such as those used with HTML and XML. I see no reason for repeating here errors done in the past. MathML is not way. >> A) Eliminate next text from specification >> >> "Authors are encouraged to use MathML for marking up mathematics" >> >> because authors would use more concise powerful and solid markup for >> mathematics. > > -1 at least until an alternative is implemented and deployed in UAs. MathML is not alternative at all as 10 years verified. Any other alternative approach could be implemented in browsers in a few days, because one can reuse working HTML, CSS, and DOM. Moreover advantages of this kind of approach I am suggesting are applicable beyond mathematics. For example a better support for the standard CSS block-inline is crucial for mathematical rendering. But a better support of the rule benefits also rendering of other kind of documents. A better support for <mroot> in MathML only benefits mathematical documents prepared using p-MathML. >> C) A more complete approach is providing a set of structural and/or >> semantic tags for usage with HTML5. > > Scope creep. ????? >> One needs little tags, because <sub>, <sup>, <var> and <table> can be >> reused. > > I don't believe that considering that vast feature set LaTeX needs to > provide. Unfortunately, LaTeX design is erratic obligating to introduce billions of redundant commands, each one with different syntax, content model, etc. A typical example is LaTeX redundancy between \frac and \over for fractions. Nothing of that is needed in XML-MAIDEN or in ISO 12083, the international standard for mathematics on SGML. It is clear that a combination of tags more powerful CSS rules more Unicode is all one needs. For instance, amstex package provides you a special command with two attributes for placing indices in certain roots. This non-modular approach is unnecessary in SGML/XML/HTML. A stylesheet (CSS, DSSL, XSL-FO) generates default rendering but you can do fine-tuning of position of the index via standard CSS rules applied to special element (you can modify colors, stretching, kerning, heights, baselines, margins, paddings, positions, etc. and many more things LaTeX cannot via CSS). In amstex you need a special command for vertical align of index in the root, in CSS you could use the standard vertical-align command you use for rendering any other text. But again apple and oranges. I am explaining that one can provide a better support for online mathematics than using presentation MathML just by addition of a few tags to the future HTML. Your appeal to LaTeX appears a bit off topic and in any case is not relevant for not considering my proposal of avoiding MathML as mathematical markup. > -- > Henri Sivonen > hsivonen at iki.fi > http://hsivonen.iki.fi/ > Juan R. Center for CANONICAL |SCIENCE)Received on Saturday, 27 May 2006 10:10:42 UTC

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