------------------------------------------------------------------------ Using Sets of Mathematical Tools A session at CADGME 2016 7--10 September 2016, Targu Mures, Romania https://cadgme.ms.sapientia.ro ------------------------------------------------------------------------ Mathematical softwares are diverse and rich. Each software can perform some tasks very well and others only with big efforts. This session aims at exploring the possibility to teach mathematics and mathematical tools when using them /together/: How can one use the systems productively, keeping the best of each software's functionality when teaching and using? We invite contributions about the exchange between computing systems such as the following: * user reports (expectations, obtained results) * teaching directions when working with several systems * scenarios of teaching of exchanges that can be effective for the education * standards and their applicability in the exchanges * technical tools that can facilitate the exchanges There is just a week left till the end of the submission period for the abstracts and posters at the CADGME conference (May 2nd). * abstracts of a presentation are max 300 words big sketch the intended presentation to be done at the conference * posters will be presented in an expo environment so as to introduce discussion We look forward to your contributions! https://cadgme.ms.sapientia.ro.

Dear Translators And Dear W3C Math mailing list Members I change URL of sume translations about MathML into Japanese of the following document: (1) MathML for CSS Profile(http://www.w3.org/TR/2011/REC-mathml-for-css-20110607/) CSSに対応するMathMLの概要書(http://takamu.sakura.ne.jp/mathml-for-css-ja.html) Previous URL http://www3.fctv.ne.jp/~takamu/mathml-for-css-ja.html (2) XML Entity Definitions for Characters(http://www.w3.org/TR/2010/REC-xml-entity-names-20100401/) 文字に対するXML実体の定義(http://takamu.sakura.ne.jp/xml-entity-names-ja/index.html) Previous URL http://www3.fctv.ne.jp/~takamu/xml-entity-names-ja/index.html (3) Units in MathML(https://www.w3.org/TR/2003/NOTE-mathml-units-20031110/) MathMLにおける単位(http://takamu.sakura.ne.jp/mathml-units-ja.htm) Previous URL http://www3.fctv.ne.jp/~takamu/mathml-units-ja.htm Sincerely 16.Apr.2016 高村 吉一(Yoshikazu Takamura) MailAdress : soco__kankyo@hotmail.com

On 2016/4/16 20:38, 高村 吉一 wrote: > Dear Translators > And Dear W3C Math mailing list Members > > I change URL of sume translations about MathML into Japanese of the following document: > > (1) MathML for CSS Profile(http://www.w3.org/TR/2011/REC-mathml-for-css-20110607/) > CSSに対応するMathMLの概要書(http://takamu.sakura.ne.jp/mathml-for-css-ja.html) > Previous URL http://www3.fctv.ne.jp/~takamu/mathml-for-css-ja.html > > (2) XML Entity Definitions for Characters(http://www.w3.org/TR/2010/REC-xml-entity-names-20100401/) > 文字に対するXML実体の定義(http://takamu.sakura.ne.jp/xml-entity-names-ja/index.html) > Previous URL http://www3.fctv.ne.jp/~takamu/xml-entity-names-ja/index.html Dear Yoshikazu, Thanks for your information and now they are updated in the translation database: Cf. <https://www.w3.org/2005/11/Translations/Query?rec=any&lang=ja&translator=Yoshikazu_Takamura&date=any&sorting=byTechnology&output=FullHTML&submit=Submit> > (3) Units in MathML(https://www.w3.org/TR/2003/NOTE-mathml-units-20031110/) > MathMLにおける単位(http://takamu.sakura.ne.jp/mathml-units-ja.htm) > Previous URL http://www3.fctv.ne.jp/~takamu/mathml-units-ja.htm Please note that, as of 2012, only translations of W3C Recommendations will be added to the Translations Database. So the Group Note translation will not be included in the DB according to the announcement: https://lists.w3.org/Archives/Public/w3c-translators/2012JulSep/0038.html Many thanks and all of your translations are much appreciated. Best, Xueyuan > Sincerely > > 16.Apr.2016 > > 高村 吉一(Yoshikazu Takamura) > MailAdress : soco__kankyo@hotmail.com >

Call for Papers: MathUI'16 http://www.cicm-conference.org/2016/cicm.php?event=mathui ------------------------------------------------------------------------ 10^th Mathematical User Interfaces Workshop 2016 ------------------------------------------------------------------------ at the Conference on Intelligent Computer Mathematics Bialystok, Poland on Monday 25^th of July 2016 ------------------------------------------------------------------------ please redistribute SCOPE MathUI is an international workshop to discuss how users can be best supported when doing/learning/searching for/interacting with mathematics using a computer. * Is mathematical user interface design a design for representing mathematics, embedding mathematical context, or a specific design for mathematicians? * How is mathematics for which purpose best represented? * What specifically math-oriented support is needed? * Does learning of math require a platform different than other learning platforms? * Which mathematical services can be offered? * Which services can be meaningfully combined? * What best practices wrt. mathematics can be found and how can they be best communicated? We invite all questions, that care for the use of mathematics on computers and how the user experience can be improved, to be discussed in the workshop. TOPICS include * user-requirements for math interfaces * presentation formats for mathematical content * mobile-devices powered mathematics * cultural differences in practices of mathematical languages * didactically sensible mathematical scenarios of use * spreadsheets as mathematical interfaces * manipulations of mathematical expressions This workshop follows a successful series of workshops held at the Conferences on Intelligent Computer Mathematics since 11 years; it features presentations of brand new ideas in papers selected by a thorough review process, wide space for discussions,as well as a software demonstration session. SUBMISSIONS The organizers invite authors to submit contributions of 6 to 12 pages on the workshop-related topics in PDF format optionally illustrated by supplementary media such as video recordings or access to demos. DEADLINE for submissions: May 30^th 2015. Method of submission: please login and submit via EasyChair: https://easychair.org/conferences/?conf=mathui16. The submissions will be reviewed by the international programme committee whose comments and recommendations will be sent back by June 19^th requesting a final version no later than July 2^nd . Moreover, MathUI will be concluded by an exhibit-like demonstration session. Proposed demonstrations should be sent by email until June 20th, containing a URL to a software description, a title, a short abstract of the demonstrated features, and the indication of hardware expectations (own/lent laptop/tablet, internet access (speed?), power, ...). After a short elevator pitch, the demonstration session will run for 1-3h, each demonstrating to interested parties. REVIEW COMMITTEE (to be confirmed) * Finland o Olga Caprotti, University of Helsinki * France o Jana Trgalova, Universite Claude Bernard Lyon 1 * Germany o Andrea Kohlhase (organizer), Neu-Ulm University of Applied Sciences o Peter Krautzberger, krautzource UG, Bonn o Paul Libbrecht (organizer), University of Education of Weingarten * Great Britain o Chris Rowley * Netherlands o Jan Willem Knopper, Technische Universiteit Eindhoven * Spain o Daniel Marquès, wiris, Barcelona * USA o Deyan Ginev, Authorea, New York o Elena Smirnova, Texas Instruments Inc. Education Technology For inquiries please contact * Paul Libbrecht, paul@cermat.org or * Andrea Kohlhase, Andrea.Kohlhase@hs-neu-ulm.de

Rather than discussing whether MathML is a failed standard, web or otherwise, I recommend we discuss specific, constructive topics. I suggest the discussion be in the context of MathML where appropriate, not because I want to defend MathML but because it is an existing standard. It is a place to start. If the solutions we reach replace MathML all or in part, so be it. Let's not start by throwing it out but by addressing its problems. We can certainly create a new standard if MathML can't be fixed. Finally, if this is the wrong venue for this topic or any other, please suggest a better one. If there are other parties that need to know about the discussion, please let them know. Assuming others agree, let’s start with perhaps an important issue. Should Presentation MathML dictate a specific rendering or leave formatting choices up to the renderer. Peter says, "I have the impression people generally expect consistent rendering across browsers. But anecdotal evidence is, well, anecdotal." I would agree with this statement. People do expect this. I believe they get that expectation from TeX but it does make sense. Why would a user want a different rendering in a different browser? The reason I said "no" to this before was because the MathML spec leaves a lot of rendering decisions up to the implementation. Someone reading the MathML spec should NOT expect all renderings to be the same. In fact, the spec doesn't specify the rendering at the required level of detail. Doing so would be difficult. TeX doesn't specify its rendering in detail either except via the code itself. In other words, the only proper rendering of TeX is that done by TeX itself. We could create a MathML 4 in which the graphical rendering is specified in writing and in detail. Implementations would be constrained much more than by the current spec. Another way to achieve this goal is to create a reference implementation. This would be the TeX way, or close to it. We could even map MathML onto TeX somehow and then defer to TeX's rendering. The MathML spec would be annotated by TeX templates (perhaps macros) that serve to define the rendering. The reference implementation would consist of a MathML-to-TeX convertor and the TeX engine itself. Implementations that intend to abide by the MathML 4 spec could use the reference implementation or roll their own. When I say rendering above, I only mean graphical rendering. When we talk about audio or braille rendering, things are much less clear. The state of the art in MathML-to-speech has certainly not reached a point where everyone can agree. Besides, there is personal taste of the reader and multiple languages to consider. Ok, I'll stop there and take a breath. Paul

Paul commented "TeX doesn't specify its rendering in detail either except via the code itself. In other words, the only proper rendering of TeX is that done by TeX itself." Actually Appendix G of The TeXbook describes how TeX lays out math. The Office math layout program<https://blogs.msdn.microsoft.com/murrays/2006/11/14/lineservices/> uses the algorithms therein, which is why the results look so much like TeX. The actual code is completely different from TeX’s, but the layout principles are generally the same. It’s good to have this discussion. Clearly Presentation MathML is used a lot for interchanging math zones between programs. Also I haven’t given up on the idea of the browsers rendering MathML well natively. If IE ever succeeds, it’ll likely look like TeX, since both IE and Edge use LineServices<https://blogs.msdn.microsoft.com/murrays/2006/11/14/lineservices/>. And it should be way faster than Java script code. My main complaints about Presentation MathML are 1) lack of an explicit n-ary element (for integrals, summations, products, etc.) and 2) lack of document level math properties<https://blogs.msdn.microsoft.com/murrays/2008/10/27/default-document-math-properties/>, like default math font. Also Presentation MathML depends too much on proper use of <mrow>, which wouldn’t even be needed if the elements were all “prefix” elements like <mfrac> and <mfenced>. But infix notation can be translated to prefix notation, a good example being conversion of the linear format<http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf> to the OMML<https://blogs.msdn.microsoft.com/murrays/2006/10/06/mathml-and-ecma-math-omml/>-like internal format for LineServices. Similarly RichEdit’s MathML reader converts using the rich-text string stack<https://msdn.microsoft.com/en-us/library/windows/desktop/hh768736(v=vs.85).aspx> originally developed for the linear format. The bottom line is that MathML isn’t perfect, but it’s a widely used standard and gets the job done. As such, it’s hardly a failure. And it’s nicely supported on the web thanks to MathJax. Murray

Murray, I guess I forgot about Appendix G of the TeXbook. Thanks for the correction. Did you find that it defined the rendering accurately enough for your line services implementation? Since it has OpenType ‘math’ table support, does it really render exactly as TeX? I guess one could say that the two implementations render the same modulo the fonts used. Did your line services improve on TeX math rendering at all or fill in any gaps in Appendix G. Were there any concessions made to compatibility with layout of non-math text? I am not asking these questions to argue against your point. I’m just suggesting that while a reader may regard two renderings as being equal, there may still be unavoidable, or by-design, differences due to variations in rendering technology, software environment, and other considerations. Paul From: Murray Sargent [mailto:murrays@exchange.microsoft.com] Sent: Friday, April 8, 2016 2:34 PM To: Paul Topping <pault@dessci.com>; Daniel Kinzler <daniel@brightbyte.de>; Moritz Schubotz <schubotz@tu-berlin.de>; www-math@w3.org; Peter Krautzberger <peter.krautzberger@mathjax.org> Cc: Wikimedia developers <wikitech-l@lists.wikimedia.org>; wikidata-tech <wikidata-tech@lists.wikimedia.org> Subject: RE: should MathML dictate a specific graphical rendering Paul commented "TeX doesn't specify its rendering in detail either except via the code itself. In other words, the only proper rendering of TeX is that done by TeX itself." Actually Appendix G of The TeXbook describes how TeX lays out math. The Office math layout program<https://blogs.msdn.microsoft.com/murrays/2006/11/14/lineservices/> uses the algorithms therein, which is why the results look so much like TeX. The actual code is completely different from TeX’s, but the layout principles are generally the same. It’s good to have this discussion. Clearly Presentation MathML is used a lot for interchanging math zones between programs. Also I haven’t given up on the idea of the browsers rendering MathML well natively. If IE ever succeeds, it’ll likely look like TeX, since both IE and Edge use LineServices<https://blogs.msdn.microsoft.com/murrays/2006/11/14/lineservices/>. And it should be way faster than Java script code. My main complaints about Presentation MathML are 1) lack of an explicit n-ary element (for integrals, summations, products, etc.) and 2) lack of document level math properties<https://blogs.msdn.microsoft.com/murrays/2008/10/27/default-document-math-properties/>, like default math font. Also Presentation MathML depends too much on proper use of <mrow>, which wouldn’t even be needed if the elements were all “prefix” elements like <mfrac> and <mfenced>. But infix notation can be translated to prefix notation, a good example being conversion of the linear format<http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf> to the OMML<https://blogs.msdn.microsoft.com/murrays/2006/10/06/mathml-and-ecma-math-omml/>-like internal format for LineServices. Similarly RichEdit’s MathML reader converts using the rich-text string stack<https://msdn.microsoft.com/en-us/library/windows/desktop/hh768736(v=vs.85).aspx> originally developed for the linear format. The bottom line is that MathML isn’t perfect, but it’s a widely used standard and gets the job done. As such, it’s hardly a failure. And it’s nicely supported on the web thanks to MathJax. Murray

The LineServices post<https://blogs.msdn.microsoft.com/murrays/2006/11/14/lineservices/> includes a description of an incredible afternoon several of us spent with Donald Knuth back in 2004. Among many things, he demonstrated how he tweaks<https://blogs.msdn.microsoft.com/murrays/2011/04/30/two-math-typography-niceties/> his TeX documents. We did automate some of these tweaks, notably creating “cut-ins” for subscript/superscript positioning. These cut-ins are part of the OpenType math spec<https://blogs.msdn.microsoft.com/murrays/2014/04/27/opentype-math-tables/>. Knuth explained that he didn’t want to go back and change TeX due to its archival usage. Naturally non-math concepts such as revision tracking and embedded objects along with international text had to be accommodated in our implementation. This was another reason for using OMML instead of MathML as the preferred math XML; you can embed other XMLs into OMML. In principle you can do that using the MathML <semantics> element, but it’d be somewhat cumbersome. The Office layout is essentially the same as TeX’s. It’ll be interesting to see how the two compare when the STIX font is finally released with full OpenType math table support. Tyro Typeworks<http://www.tiro.com/> is handling this and it also did Cambria Math. Murray From: Paul Topping [mailto:pault@dessci.com] Sent: Friday, April 8, 2016 3:03 PM To: Murray Sargent <murrays@exchange.microsoft.com>; Daniel Kinzler <daniel@brightbyte.de>; Moritz Schubotz <schubotz@tu-berlin.de>; www-math@w3.org; Peter Krautzberger <peter.krautzberger@mathjax.org> Cc: Wikimedia developers <wikitech-l@lists.wikimedia.org>; wikidata-tech <wikidata-tech@lists.wikimedia.org> Subject: RE: should MathML dictate a specific graphical rendering Murray, I guess I forgot about Appendix G of the TeXbook. Thanks for the correction. Did you find that it defined the rendering accurately enough for your line services implementation? Since it has OpenType ‘math’ table support, does it really render exactly as TeX? I guess one could say that the two implementations render the same modulo the fonts used. Did your line services improve on TeX math rendering at all or fill in any gaps in Appendix G. Were there any concessions made to compatibility with layout of non-math text? I am not asking these questions to argue against your point. I’m just suggesting that while a reader may regard two renderings as being equal, there may still be unavoidable, or by-design, differences due to variations in rendering technology, software environment, and other considerations. Paul From: Murray Sargent [mailto:murrays@exchange.microsoft.com] Sent: Friday, April 8, 2016 2:34 PM To: Paul Topping <pault@dessci.com<mailto:pault@dessci.com>>; Daniel Kinzler <daniel@brightbyte.de<mailto:daniel@brightbyte.de>>; Moritz Schubotz <schubotz@tu-berlin.de<mailto:schubotz@tu-berlin.de>>; www-math@w3.org<mailto:www-math@w3.org>; Peter Krautzberger <peter.krautzberger@mathjax.org<mailto:peter.krautzberger@mathjax.org>> Cc: Wikimedia developers <wikitech-l@lists.wikimedia.org<mailto:wikitech-l@lists.wikimedia.org>>; wikidata-tech <wikidata-tech@lists.wikimedia.org<mailto:wikidata-tech@lists.wikimedia.org>> Subject: RE: should MathML dictate a specific graphical rendering Paul commented "TeX doesn't specify its rendering in detail either except via the code itself. In other words, the only proper rendering of TeX is that done by TeX itself." Actually Appendix G of The TeXbook describes how TeX lays out math. The Office math layout program<https://blogs.msdn.microsoft.com/murrays/2006/11/14/lineservices/> uses the algorithms therein, which is why the results look so much like TeX. The actual code is completely different from TeX’s, but the layout principles are generally the same. It’s good to have this discussion. Clearly Presentation MathML is used a lot for interchanging math zones between programs. Also I haven’t given up on the idea of the browsers rendering MathML well natively. If IE ever succeeds, it’ll likely look like TeX, since both IE and Edge use LineServices<https://blogs.msdn.microsoft.com/murrays/2006/11/14/lineservices/>. And it should be way faster than Java script code. My main complaints about Presentation MathML are 1) lack of an explicit n-ary element (for integrals, summations, products, etc.) and 2) lack of document level math properties<https://blogs.msdn.microsoft.com/murrays/2008/10/27/default-document-math-properties/>, like default math font. Also Presentation MathML depends too much on proper use of <mrow>, which wouldn’t even be needed if the elements were all “prefix” elements like <mfrac> and <mfenced>. But infix notation can be translated to prefix notation, a good example being conversion of the linear format<http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf> to the OMML<https://blogs.msdn.microsoft.com/murrays/2006/10/06/mathml-and-ecma-math-omml/>-like internal format for LineServices. Similarly RichEdit’s MathML reader converts using the rich-text string stack<https://msdn.microsoft.com/en-us/library/windows/desktop/hh768736(v=vs.85).aspx> originally developed for the linear format. The bottom line is that MathML isn’t perfect, but it’s a widely used standard and gets the job done. As such, it’s hardly a failure. And it’s nicely supported on the web thanks to MathJax. Murray

Murray Sargent writes in part: > It's good to have this discussion. Clearly Presentation > MathML is used a lot for interchanging math zones between > programs. Also I haven't given up on the idea of the > browsers rendering MathML well natively. If IE ever > succeeds, it'll likely look like TeX, since both IE and > Edge use LineServices. And it should be way faster than > Java script code. This would be good to see. -- Bill

On 04/09/2016 02:42 PM, William F Hammond wrote: > Murray Sargent writes in part: > >> It's good to have this discussion. Clearly Presentation >> MathML is used a lot for interchanging math zones between >> programs. Also I haven't given up on the idea of the >> browsers rendering MathML well natively. If IE ever >> succeeds, it'll likely look like TeX, since both IE and >> Edge use LineServices. And it should be way faster than >> Java script code. > > This would be good to see. Oh, this would more than "good", it would be... Well, let's go with the ever popular Sports Analogies: It would be a game changer. Moreover, knowing Murray, I have no doubt that it'd reset the bar for math rendering on the web. Sigh. It's all the more frustrating in that MS has already done the hard part (not to trivialize the integration & testing). bruce

Hi Daniel, Ok. Let's discuss! Most interesting for me is Peters statements > Content MathML is just not relevant. Since I'm currently investigating how content MathML is used, and whats needs to be done to get mathematical content from one system to another. Currently, I have the impression that the latter question is completely solved in theory, but completely unsolved in practise. Disclaimer: While I really appreciate drinking beer with Peter, we have slightly different approaches for de facto standards to share mathematics in information systems. Best Moritz On Thu, Apr 7, 2016 at 1:24 PM, Daniel Kinzler <daniel@brightbyte.de> wrote: > Peter Krautzberger, maintainer of MathJax, apparently thinks that MathML has > failed as a web standard (even though it succeeded as an XML standard), and > should be removed from HTML5. Here's the link: > > https://www.peterkrautzberger.org/0186/ > > It's quite a rant. Here's a quick TL;DR: > >> It doesn’t matter whether or not MathML is a good XML language. Personally, I >> think it’s quite alright. It’s also clearly a success in the XML publishing >> world, serving an important role in standards such as JATS and BITS. >> >> The problem is: MathML has failed on the web. > >> Not a single browser vendor has stated an intent to work on the code, not a >> single browser developer has been seen on the MathWG. After 18 years, not a >> single browser vendor is willing to dedicate even a small percentage of a >> developer to MathML. > >> Math layout can and should be done in CSS and SVG. Let’s improve them >> incrementally to make it simpler. >> >> It’s possible to generate HTML+CSS or SVG that renders any MathML content – >> on the server, mind you, no client-side JS required (but of course possible). > >> Since layout is practically solved (or at least achievable), we really need >> to solve the semantics. Presentation MathML is not sufficient, Content MathML >> is just not relevant. >> >> We need to look where the web handles semantics today – that’s ARIA and HTML >> but also microdata, rdfa etc. > > I think both, the rendering as well as the semantics, are well worth thinking > about. Perhaps Wikimedia should reach out to Peter Krautzberger, and discuss > some ideas of how math (and physics, and chemistry) content should be handled by > Wikipedia, Wikidata, and friends. This seems like a cross roads, and we should > have a hand in where things are going from here. > > -- daniel (not a MathML expert all all) > -- Moritz Schubotz TU Berlin, Fakultät IV DIMA - Sekr. EN7 Raum EN742 Einsteinufer 17 D-10587 Berlin Germany Tel.: +49 30 314 22784 Mobil.: +49 1578 047 1397 Fax: +49 30 314 21601 E-Mail: schubotz@tu-berlin.de Skype: Schubi87 ICQ: 200302764 Msn: Moritz@Schubotz.de

Yes, let's discuss. I wrote a response to Peter's post here: http://bit.ly/1ZLfCF8. Probably some on this list are aware of it but perhaps not all. I believe it is important to separate out the different aspects of MathML as a standard. Peter scoped his post by saying that it had failed as a WEB standard right in the title. However, many will ignore that key word and see it as saying that MathML is a total failure which is clearly not the case. On Hacker News, they even discussed how TeX was a better language than MathML to type math. Peter's title is a provocative one and subject to much misinterpretation. This is one of the main reasons I wrote my response. I actually agree with a lot of Peter's observations but not their tone and the fact that they are presented in a manner that invites misinterpretation by the many that do not really understand MathML. Paul Topping Design Science, Inc. "How Science Communicates" Makers of MathType, MathFlow, MathPlayer, Equation Editor http://www.dessci.com > -----Original Message----- > From: Moritz Schubotz [mailto:schubotz@tu-berlin.de] > Sent: Thursday, April 07, 2016 11:01 AM > To: Daniel Kinzler <daniel@brightbyte.de>; www-math@w3.org; Peter > Krautzberger <peter.krautzberger@mathjax.org> > Cc: Wikimedia developers <wikitech-l@lists.wikimedia.org>; Schubotz, > Moritz <schubotz@tu-berlin.de>; wikidata-tech <wikidata- > tech@lists.wikimedia.org> > Subject: Re: MathML is dead, long live MathML > > Hi Daniel, > > Ok. Let's discuss! > > Most interesting for me is Peters statements > > Content MathML is just not relevant. > Since I'm currently investigating how content MathML is used, and > whats needs to be done to get mathematical content from one system to > another. > Currently, I have the impression that the latter question is > completely solved in theory, but completely unsolved in practise. > > Disclaimer: While I really appreciate drinking beer with Peter, we > have slightly different approaches for de facto standards to share > mathematics in information systems. > > Best > Moritz > > > On Thu, Apr 7, 2016 at 1:24 PM, Daniel Kinzler <daniel@brightbyte.de> wrote: > > Peter Krautzberger, maintainer of MathJax, apparently thinks that MathML > has > > failed as a web standard (even though it succeeded as an XML standard), > and > > should be removed from HTML5. Here's the link: > > > > https://www.peterkrautzberger.org/0186/ > > > > It's quite a rant. Here's a quick TL;DR: > > > >> It doesn’t matter whether or not MathML is a good XML language. > Personally, I > >> think it’s quite alright. It’s also clearly a success in the XML publishing > >> world, serving an important role in standards such as JATS and BITS. > >> > >> The problem is: MathML has failed on the web. > > > >> Not a single browser vendor has stated an intent to work on the code, not > a > >> single browser developer has been seen on the MathWG. After 18 years, > not a > >> single browser vendor is willing to dedicate even a small percentage of a > >> developer to MathML. > > > >> Math layout can and should be done in CSS and SVG. Let’s improve them > >> incrementally to make it simpler. > >> > >> It’s possible to generate HTML+CSS or SVG that renders any MathML > content – > >> on the server, mind you, no client-side JS required (but of course > possible). > > > >> Since layout is practically solved (or at least achievable), we really need > >> to solve the semantics. Presentation MathML is not sufficient, Content > MathML > >> is just not relevant. > >> > >> We need to look where the web handles semantics today – that’s ARIA > and HTML > >> but also microdata, rdfa etc. > > > > I think both, the rendering as well as the semantics, are well worth thinking > > about. Perhaps Wikimedia should reach out to Peter Krautzberger, and > discuss > > some ideas of how math (and physics, and chemistry) content should be > handled by > > Wikipedia, Wikidata, and friends. This seems like a cross roads, and we > should > > have a hand in where things are going from here. > > > > -- daniel (not a MathML expert all all) > > > > > > -- > Moritz Schubotz > TU Berlin, Fakultät IV > DIMA - Sekr. EN7 > Raum EN742 > Einsteinufer 17 > D-10587 Berlin > Germany > > Tel.: +49 30 314 22784 > Mobil.: +49 1578 047 1397 > Fax: +49 30 314 21601 > E-Mail: schubotz@tu-berlin.de > Skype: Schubi87 > ICQ: 200302764 > Msn: Moritz@Schubotz.de

Am 07.04.2016 um 20:00 schrieb Moritz Schubotz: > Hi Daniel, > > Ok. Let's discuss! Great! But let's keep the discussion in one place. I made a mess by cross-posting this to two lists, now it's three, it seems. Can we agree on <wikitech-l@lists.wikimedia.org> as the venue of discussion? At least for the discussion of MathML in the context of Wikimedia, that would be the best place, I think. -- daniel

I have no problem with that but are some of these lists members-only? I was told when I replied that my message would be reviewed by the moderator as I wasn't a member. Perhaps that was the W3C list. Paul > -----Original Message----- > From: Daniel Kinzler [mailto:daniel@brightbyte.de] > Sent: Thursday, April 07, 2016 11:06 AM > To: Moritz Schubotz <schubotz@tu-berlin.de>; www-math@w3.org; Peter > Krautzberger <peter.krautzberger@mathjax.org> > Cc: Wikimedia developers <wikitech-l@lists.wikimedia.org>; wikidata-tech > <wikidata-tech@lists.wikimedia.org> > Subject: Re: MathML is dead, long live MathML > > Am 07.04.2016 um 20:00 schrieb Moritz Schubotz: > > Hi Daniel, > > > > Ok. Let's discuss! > > Great! But let's keep the discussion in one place. I made a mess by > cross-posting this to two lists, now it's three, it seems. Can we agree on > <wikitech-l@lists.wikimedia.org> as the venue of discussion? At least for the > discussion of MathML in the context of Wikimedia, that would be the best > place, > I think. > > -- daniel > >

Peter just posted a follow up response, largely commenting on my response: https://www.peterkrautzberger.org/0187/. First, I suspect the reason his post doesn't get as much discussion as he'd like is because his blog doesn't accept comments. I can understand why he doesn't enable comments on his personal blog but why not post it somewhere that DOES accept comments? He says that most of the discussion has been private. That is not the way to change a standard or replace it by a new one. By all means have your private conversations but don't expect others to agree with any conclusions reached in them. The result of good ideas expressed in private conversation should be to introduce them into public conversation. Instead, his post treated MathML's failure as a fait accompli. Perhaps it is but only in the narrow scope of it being ignored by browser makers. He feels that many things I said in my reply were more about expressing my own ideas. I'll cop to that. I felt that was needed to indicate that there are other points of view and other ideas. His solutions may not be the right ones. Let's open up the discussion. Can we identify specific topics worthy of addressing and discuss them? I tried to hint at some possible directions in my reply, which is why it veered into some of my own ideas. I would love for this to be a constructive discussion. Instead of discussing whether MathML is a failed standard, I would like to see real, open discussion on solutions to various problems. Any takers? Paul > -----Original Message----- > From: Paul Topping [mailto:pault@dessci.com] > Sent: Thursday, April 07, 2016 2:02 PM > To: Daniel Kinzler <daniel@brightbyte.de>; Moritz Schubotz <schubotz@tu- > berlin.de>; www-math@w3.org; Peter Krautzberger > <peter.krautzberger@mathjax.org> > Cc: Wikimedia developers <wikitech-l@lists.wikimedia.org>; wikidata-tech > <wikidata-tech@lists.wikimedia.org> > Subject: RE: MathML is dead, long live MathML > > I have no problem with that but are some of these lists members-only? I was > told when I replied that my message would be reviewed by the moderator as > I wasn't a member. Perhaps that was the W3C list. > > Paul > > > -----Original Message----- > > From: Daniel Kinzler [mailto:daniel@brightbyte.de] > > Sent: Thursday, April 07, 2016 11:06 AM > > To: Moritz Schubotz <schubotz@tu-berlin.de>; www-math@w3.org; Peter > > Krautzberger <peter.krautzberger@mathjax.org> > > Cc: Wikimedia developers <wikitech-l@lists.wikimedia.org>; wikidata-tech > > <wikidata-tech@lists.wikimedia.org> > > Subject: Re: MathML is dead, long live MathML > > > > Am 07.04.2016 um 20:00 schrieb Moritz Schubotz: > > > Hi Daniel, > > > > > > Ok. Let's discuss! > > > > Great! But let's keep the discussion in one place. I made a mess by > > cross-posting this to two lists, now it's three, it seems. Can we agree on > > <wikitech-l@lists.wikimedia.org> as the venue of discussion? At least for > the > > discussion of MathML in the context of Wikimedia, that would be the best > > place, > > I think. > > > > -- daniel > > > >

Am 07.04.2016 um 23:01 schrieb Paul Topping: > I have no problem with that but are some of these lists members-only? I was > told when I replied that my message would be reviewed by the moderator as I > wasn't a member. Perhaps that was the W3C list. Oh... both the Wikimedia lists are members only, I'm afraid. The W3C list requires a 1-click agreement to their terms. That's easier, but less likely to involve Wikimedia people.

Hello, how many of us have github accounts? On Friday, April 8, 2016 6:10 AM, Daniel Kinzler <daniel@brightbyte.de> wrote: Am 07.04.2016 um 23:01 schrieb Paul Topping: > I have no problem with that but are some of these lists members-only? I was > told when I replied that my message would be reviewed by the moderator as I > wasn't a member. Perhaps that was the W3C list. Oh... both the Wikimedia lists are members only, I'm afraid. The W3C list requires a 1-click agreement to their terms. That's easier, but less likely to involve Wikimedia people.

Hi Daniel, Could you let me know once you've decided on a venue for discussion? I'd be happy to join in. Thanks in advance, Peter. On Thu, Apr 7, 2016 at 8:05 PM, Daniel Kinzler <daniel@brightbyte.de> wrote: > Am 07.04.2016 um 20:00 schrieb Moritz Schubotz: > > Hi Daniel, > > > > Ok. Let's discuss! > > Great! But let's keep the discussion in one place. I made a mess by > cross-posting this to two lists, now it's three, it seems. Can we agree on > <wikitech-l@lists.wikimedia.org> as the venue of discussion? At least for > the > discussion of MathML in the context of Wikimedia, that would be the best > place, > I think. > > -- daniel > >

Hi, Peter Krautzberger of MathJax fame, recently posted this on his own blog: MathML is a failed web standard https://www.peterkrautzberger.org/0186/ Obviously, he presents some challenges to the MathML standard and its community. I felt that I had to respond: Response to Peter Krautzberger's "MathML is a failed web standard" http://bit.ly/1ZLfCF8 I hope this exchange prompts some serious dialog. Paul Topping Design Science, Inc. "How Science Communicates" Makers of MathType, MathFlow, MathPlayer, Equation Editor http://www.dessci.com

I write as a chemist who has tried to do the same thing with Chemistry (CML, Chemical Markup Language). I have been inspired by what I see as the success of MathML and do not regard it as a failure. I am particularly interested in Content MathML as computable maths. The reality seems to be that it takes a generation for many of these ideas to be implemented. in 1998 SVG seemed to be the obvious way of doing graphics, but after 5 years it looked close to death. After 15 years it's become universal. CML is used by a small number of enthusiasts. The chemical software manufacturers don't care because they only care about the pharma industry and instruments. So we strugle on with a number of ad hoc broken representations of chemistry, which are still primarily graphical. There is almost no chemistry for blind people. The real problem is semantics. At the moment the world doesn't care. They will have to in the future. IoT demands semantics. You cannot compute pictures. Binding semantics to maths and chemistry is hard but it will have to come. I'd guess that people will need semantic math in 5 years and chemistry in 15. If you let the world be driven by browser manufacturers and publishers you will get a sighted-human vision of maths and science. The IoT won't need browsers. It WILL need semantic maths. On Fri, Apr 1, 2016 at 11:10 PM, Paul Topping <pault@dessci.com> wrote: > Hi, > > Peter Krautzberger of MathJax fame, recently posted this on his own blog: > > MathML is a failed web standard > https://www.peterkrautzberger.org/0186/ > > Obviously, he presents some challenges to the MathML standard and its > community. I felt that I had to respond: > > Response to Peter Krautzberger's "MathML is a failed web standard" > http://bit.ly/1ZLfCF8 > > I hope this exchange prompts some serious dialog. > > Paul Topping > > Design Science, Inc. > "How Science Communicates" > Makers of MathType, MathFlow, MathPlayer, Equation Editor > http://www.dessci.com > > > > > -- Peter Murray-Rust Reader in Molecular Informatics Unilever Centre, Dep. Of Chemistry University of Cambridge CB2 1EW, UK +44-1223-763069

Dear MathML Subscribers, I must admit that I have not read every word of both posts, but I already know what this is about, because I have already encountered similar issues, with both Presentation and Content. I'm not too concerned with Presentation, because MathJax does an excellent job at that. What I am concerned with is Content (i.e. Semantics), and to quote the original article: "Content MathML is just not relevant." -- Peter Krautzberger I have been writing a set of tools for trans-language compilation for about 5 years now, (freely available at https://github.com/andydude/droxtools), and the only system I've found that is is open, non-commercial, and easily extensible for representing arbitrary concepts from every programming language ever invented, is Content MathML. This is the opposite of "not relevant", and Paul Topping failed to address this. In my humble opinion, the reason why MathML has failed isn't because of Content MathML, it's because of Presentation MathML, and it's not because it isn't accurate, or because it doesn't look good, it's because people prefer TeX over angle brackets. MathJax provides people the ability to show the same beautiful math expressions on web pages, that Presentation MathML promised but with many fewer keystrokes. I don't care about angle brackets. I don't care about superscripts. The only thing that interests me with regards to Content MathML, is the fact that it is, at a fundamental level, a LISP where symbols are selected from URI/RDF/XML/MathML namespaces. Granted, OpenMath/MathML namespaces are naturally defined to be equivalent, but to apply to XML/QNames as well, then you need a QName to URI mapping. I've seen two of these, the "{NS}NAME" method (think Java/Ruby/Python) and the "NS::NAME" method (think JavaScript/E4X), the first one fails to produce a valid URI, but the second method does produce a valid URI, so that's what I've been using in my tools. The point is that URIs are already a carefully controlled resource, and so they are much more open than LISP's traditional filesystem based package system, or any other system I've seen. Just in the interest of full disclosure, there are closed, commercial systems out there that do trans-language compilation, like the kind I'm currently developing. https://www.semanticdesigns.com/ is an example of a corporation involved in such a business. But I whole-heartedly believe that the future of open-source software depends on having such tools available as open source tools. This is starting to sound like a rant, so I will stop it here. Actually, I changed my mind. I still have to have a Content vs. Presentation debate. As I said earlier, I agree that Presentation MathML has failed, but that's because it's a failed viewpoint. Math isn't symbols, it's semantics. From the beginning, MathML should have been about Content, not Presentation. I think if we had focused on Content all along, then we probably wouldn't be having this conversation now. Regards, Andrew Robbins On Fri, Apr 1, 2016 at 7:21 PM, Peter Murray-Rust <pm286@cam.ac.uk> wrote: > I write as a chemist who has tried to do the same thing with Chemistry > (CML, Chemical Markup Language). I have been inspired by what I see as the > success of MathML and do not regard it as a failure. I am particularly > interested in Content MathML as computable maths. > > The reality seems to be that it takes a generation for many of these ideas > to be implemented. in 1998 SVG seemed to be the obvious way of doing > graphics, but after 5 years it looked close to death. After 15 years it's > become universal. > > CML is used by a small number of enthusiasts. The chemical software > manufacturers don't care because they only care about the pharma industry > and instruments. So we strugle on with a number of ad hoc broken > representations of chemistry, which are still primarily graphical. There is > almost no chemistry for blind people. > > The real problem is semantics. At the moment the world doesn't care. They > will have to in the future. IoT demands semantics. You cannot compute > pictures. Binding semantics to maths and chemistry is hard but it will have > to come. I'd guess that people will need semantic math in 5 years and > chemistry in 15. > > If you let the world be driven by browser manufacturers and publishers you > will get a sighted-human vision of maths and science. The IoT won't need > browsers. > > It WILL need semantic maths. > > > On Fri, Apr 1, 2016 at 11:10 PM, Paul Topping <pault@dessci.com> wrote: > >> Hi, >> >> Peter Krautzberger of MathJax fame, recently posted this on his own blog: >> >> MathML is a failed web standard >> https://www.peterkrautzberger.org/0186/ >> >> Obviously, he presents some challenges to the MathML standard and its >> community. I felt that I had to respond: >> >> Response to Peter Krautzberger's "MathML is a failed web standard" >> http://bit.ly/1ZLfCF8 >> >> I hope this exchange prompts some serious dialog. >> >> Paul Topping >> >> Design Science, Inc. >> "How Science Communicates" >> Makers of MathType, MathFlow, MathPlayer, Equation Editor >> http://www.dessci.com >> >> >> >> >> > > > -- > Peter Murray-Rust > Reader in Molecular Informatics > Unilever Centre, Dep. Of Chemistry > University of Cambridge > CB2 1EW, UK > +44-1223-763069 >

Hi Andrew, You mention that you are concerned with the number of keystrokes required to enter MathML. MathML (both Content and Presentation) was never intended to be typed by humans entering math into a computer. MathML is only a computer representation, an internal format to be written and read by software. If you prefer to type your math using TeX, that’s not a strike against MathML. As far as Content vs Presentation is concerned, it sounds like you are correctly choosing Content MathML for your purposes. Nothing wrong with that. However, that is no reason to claim that Presentation MathML has “failed”. When you say “Math isn’t symbols”, you must admit that math is indeed symbols at a certain level – that of presentation. Paul From: Andrew Robbins [mailto:andjrob@gmail.com] Sent: Friday, April 1, 2016 6:42 PM To: Peter Murray-Rust <pm286@cam.ac.uk> Cc: Paul Topping <pault@dessci.com>; www-math@w3.org Subject: Re: MathML is a failed web standard (or not?) Dear MathML Subscribers, I must admit that I have not read every word of both posts, but I already know what this is about, because I have already encountered similar issues, with both Presentation and Content. I'm not too concerned with Presentation, because MathJax does an excellent job at that. What I am concerned with is Content (i.e. Semantics), and to quote the original article: "Content MathML is just not relevant." -- Peter Krautzberger I have been writing a set of tools for trans-language compilation for about 5 years now, (freely available at https://github.com/andydude/droxtools), and the only system I've found that is is open, non-commercial, and easily extensible for representing arbitrary concepts from every programming language ever invented, is Content MathML. This is the opposite of "not relevant", and Paul Topping failed to address this. In my humble opinion, the reason why MathML has failed isn't because of Content MathML, it's because of Presentation MathML, and it's not because it isn't accurate, or because it doesn't look good, it's because people prefer TeX over angle brackets. MathJax provides people the ability to show the same beautiful math expressions on web pages, that Presentation MathML promised but with many fewer keystrokes. I don't care about angle brackets. I don't care about superscripts. The only thing that interests me with regards to Content MathML, is the fact that it is, at a fundamental level, a LISP where symbols are selected from URI/RDF/XML/MathML namespaces. Granted, OpenMath/MathML namespaces are naturally defined to be equivalent, but to apply to XML/QNames as well, then you need a QName to URI mapping. I've seen two of these, the "{NS}NAME" method (think Java/Ruby/Python) and the "NS::NAME" method (think JavaScript/E4X), the first one fails to produce a valid URI, but the second method does produce a valid URI, so that's what I've been using in my tools. The point is that URIs are already a carefully controlled resource, and so they are much more open than LISP's traditional filesystem based package system, or any other system I've seen. Just in the interest of full disclosure, there are closed, commercial systems out there that do trans-language compilation, like the kind I'm currently developing. https://www.semanticdesigns.com/ is an example of a corporation involved in such a business. But I whole-heartedly believe that the future of open-source software depends on having such tools available as open source tools. This is starting to sound like a rant, so I will stop it here. Actually, I changed my mind. I still have to have a Content vs. Presentation debate. As I said earlier, I agree that Presentation MathML has failed, but that's because it's a failed viewpoint. Math isn't symbols, it's semantics. From the beginning, MathML should have been about Content, not Presentation. I think if we had focused on Content all along, then we probably wouldn't be having this conversation now. Regards, Andrew Robbins On Fri, Apr 1, 2016 at 7:21 PM, Peter Murray-Rust <pm286@cam.ac.uk<mailto:pm286@cam.ac.uk>> wrote: I write as a chemist who has tried to do the same thing with Chemistry (CML, Chemical Markup Language). I have been inspired by what I see as the success of MathML and do not regard it as a failure. I am particularly interested in Content MathML as computable maths. The reality seems to be that it takes a generation for many of these ideas to be implemented. in 1998 SVG seemed to be the obvious way of doing graphics, but after 5 years it looked close to death. After 15 years it's become universal. CML is used by a small number of enthusiasts. The chemical software manufacturers don't care because they only care about the pharma industry and instruments. So we strugle on with a number of ad hoc broken representations of chemistry, which are still primarily graphical. There is almost no chemistry for blind people. The real problem is semantics. At the moment the world doesn't care. They will have to in the future. IoT demands semantics. You cannot compute pictures. Binding semantics to maths and chemistry is hard but it will have to come. I'd guess that people will need semantic math in 5 years and chemistry in 15. If you let the world be driven by browser manufacturers and publishers you will get a sighted-human vision of maths and science. The IoT won't need browsers. It WILL need semantic maths. On Fri, Apr 1, 2016 at 11:10 PM, Paul Topping <pault@dessci.com<mailto:pault@dessci.com>> wrote: Hi, Peter Krautzberger of MathJax fame, recently posted this on his own blog: MathML is a failed web standard https://www.peterkrautzberger.org/0186/ Obviously, he presents some challenges to the MathML standard and its community. I felt that I had to respond: Response to Peter Krautzberger's "MathML is a failed web standard" http://bit.ly/1ZLfCF8 I hope this exchange prompts some serious dialog. Paul Topping Design Science, Inc. "How Science Communicates" Makers of MathType, MathFlow, MathPlayer, Equation Editor http://www.dessci.com -- Peter Murray-Rust Reader in Molecular Informatics Unilever Centre, Dep. Of Chemistry University of Cambridge CB2 1EW, UK +44-1223-763069<tel:%2B44-1223-763069>

Hi Peter and Andrew, Thanks for those interesting statements. I'm not sure how they relate to what I wrote (please let me know if I missed something) but I appreciate having the opportunity to read them. Regards, Peter. On Sat, Apr 2, 2016 at 3:42 AM, Andrew Robbins <andjrob@gmail.com> wrote: > Dear MathML Subscribers, > > I must admit that I have not read every word of both posts, but I already > know what this is about, because I have already encountered similar issues, > with both Presentation and Content. I'm not too concerned with > Presentation, because MathJax does an excellent job at that. What I am > concerned with is Content (i.e. Semantics), and to quote the original > article: > > "Content MathML is just not relevant." -- Peter Krautzberger > > I have been writing a set of tools for trans-language compilation for > about 5 years now, (freely available at > https://github.com/andydude/droxtools), and the only system I've found > that is is open, non-commercial, and easily extensible for representing > arbitrary concepts from every programming language ever invented, is > Content MathML. This is the opposite of "not relevant", and Paul Topping > failed to address this. > > In my humble opinion, the reason why MathML has failed isn't because of > Content MathML, it's because of Presentation MathML, and it's not because > it isn't accurate, or because it doesn't look good, it's because people > prefer TeX over angle brackets. MathJax provides people the ability to show > the same beautiful math expressions on web pages, that Presentation MathML > promised but with many fewer keystrokes. > > I don't care about angle brackets. I don't care about superscripts. The > only thing that interests me with regards to Content MathML, is the fact > that it is, at a fundamental level, a LISP where symbols are selected from > URI/RDF/XML/MathML namespaces. Granted, OpenMath/MathML namespaces are > naturally defined to be equivalent, but to apply to XML/QNames as well, > then you need a QName to URI mapping. I've seen two of these, the > "{NS}NAME" method (think Java/Ruby/Python) and the "NS::NAME" method (think > JavaScript/E4X), the first one fails to produce a valid URI, but the second > method does produce a valid URI, so that's what I've been using in my > tools. The point is that URIs are already a carefully controlled resource, > and so they are much more open than LISP's traditional filesystem based > package system, or any other system I've seen. > > Just in the interest of full disclosure, there are closed, commercial > systems out there that do trans-language compilation, like the kind I'm > currently developing. https://www.semanticdesigns.com/ is an example of a > corporation involved in such a business. But I whole-heartedly believe that > the future of open-source software depends on having such tools available > as open source tools. This is starting to sound like a rant, so I will stop > it here. > > Actually, I changed my mind. I still have to have a Content vs. > Presentation debate. As I said earlier, I agree that Presentation MathML > has failed, but that's because it's a failed viewpoint. Math isn't symbols, > it's semantics. From the beginning, MathML should have been about Content, > not Presentation. I think if we had focused on Content all along, then we > probably wouldn't be having this conversation now. > > Regards, > Andrew Robbins > > > On Fri, Apr 1, 2016 at 7:21 PM, Peter Murray-Rust <pm286@cam.ac.uk> wrote: > >> I write as a chemist who has tried to do the same thing with Chemistry >> (CML, Chemical Markup Language). I have been inspired by what I see as the >> success of MathML and do not regard it as a failure. I am particularly >> interested in Content MathML as computable maths. >> >> The reality seems to be that it takes a generation for many of these >> ideas to be implemented. in 1998 SVG seemed to be the obvious way of doing >> graphics, but after 5 years it looked close to death. After 15 years it's >> become universal. >> >> CML is used by a small number of enthusiasts. The chemical software >> manufacturers don't care because they only care about the pharma industry >> and instruments. So we strugle on with a number of ad hoc broken >> representations of chemistry, which are still primarily graphical. There is >> almost no chemistry for blind people. >> >> The real problem is semantics. At the moment the world doesn't care. They >> will have to in the future. IoT demands semantics. You cannot compute >> pictures. Binding semantics to maths and chemistry is hard but it will have >> to come. I'd guess that people will need semantic math in 5 years and >> chemistry in 15. >> >> If you let the world be driven by browser manufacturers and publishers >> you will get a sighted-human vision of maths and science. The IoT won't >> need browsers. >> >> It WILL need semantic maths. >> >> >> On Fri, Apr 1, 2016 at 11:10 PM, Paul Topping <pault@dessci.com> wrote: >> >>> Hi, >>> >>> Peter Krautzberger of MathJax fame, recently posted this on his own blog: >>> >>> MathML is a failed web standard >>> https://www.peterkrautzberger.org/0186/ >>> >>> Obviously, he presents some challenges to the MathML standard and its >>> community. I felt that I had to respond: >>> >>> Response to Peter Krautzberger's "MathML is a failed web standard" >>> http://bit.ly/1ZLfCF8 >>> >>> I hope this exchange prompts some serious dialog. >>> >>> Paul Topping >>> >>> Design Science, Inc. >>> "How Science Communicates" >>> Makers of MathType, MathFlow, MathPlayer, Equation Editor >>> http://www.dessci.com >>> >>> >>> >>> >>> >> >> >> -- >> Peter Murray-Rust >> Reader in Molecular Informatics >> Unilever Centre, Dep. Of Chemistry >> University of Cambridge >> CB2 1EW, UK >> +44-1223-763069 >> > >

Going back to April 1, Andrew Robbins writes in part: > In my humble opinion, the reason why MathML has failed > isn't because of Content MathML, it's because of > Presentation MathML, and it's not because it isn't > accurate, or because it doesn't look good, it's because > people prefer TeX over angle brackets. MathJax provides > people the ability to show the same beautiful math > expressions on web pages, that Presentation MathML > promised but with many fewer keystrokes. I believe that almost all extant MathML content that I've seen originates, one way or another, with LaTeX or LaTeX-like markup. > I don't care about angle brackets. I don't care about > superscripts. The only thing that interests me with > regards to Content MathML, is the fact that it is, at a > fundamental level, a LISP where symbols are selected from > URI/RDF/XML/MathML namespaces. . . . I think it's rather difficult to generate reliably useful content MathML from LaTeX markup as commonly seen, for example, at arXiv. On the other hand, I believe that adding a LaTeX package for type declaration of mathematical symbols would go a long way toward improving this. Even better would be the use of a suitable LaTeX profile (such as I spoke about at TUG 2010 and TUG 2014) with provision for symbol type declarations. > . . . As I said earlier, I agree that Presentation MathML > has failed, but that's because it's a failed viewpoint. > Math isn't symbols, it's semantics. From the beginning, > MathML should have been about Content, not Presentation. I > think if we had focused on Content all along, then we > probably wouldn't be having this conversation now. >From the beginning the development of MathML has had two tracks with content MathML focused on content interchange and presentation MathML designed for minimizing the amount of work required for a web browser to provide a TeX-quality rendering of mathematical content from an extension of HTML markup. I disagree with the assertion that presentation MathML has failed as a web standard. It works quite well in Firefox and other Gecko browsers, and one should not forget W3C's Amaya. It is, of course, disappointing that, for the moment and for most of the time since the beginning of MathML in the late 1990s, three of the "big four" browsers have not had native support for MathML. It's a failing in the market based on crass market thinking. It was also disappointing that for the period from 2001 (if not 1995 with the dropping of HTML v 3.0) to 2011 the W3C banned any form of math content from the media type "text/html". Of course, there would be breakage of existing content if web browsers that now render MathML ceased to do so. It continues to be disappointing that search engines do not cover mathematical content well. The disappointments are not failures, but rather the result of a world where a relatively small number of individuals have any interest in mathematics. Still, native browser rendering of MathML could happen. Didn't Murray Sargent just say so? There is no reason to stop wishing for it. -- Bill