From: Robert Miner <robertm@dessci.com>

Date: Fri, 14 Jul 2006 09:24:28 -0700

Message-ID: <D1EFB337111B674B8F1BE155B01C6DD601063CAA@franklin.corp.dessci>

To: <juanrgonzaleza@canonicalscience.com>, <www-math@w3.org>

Date: Fri, 14 Jul 2006 09:24:28 -0700

Message-ID: <D1EFB337111B674B8F1BE155B01C6DD601063CAA@franklin.corp.dessci>

To: <juanrgonzaleza@canonicalscience.com>, <www-math@w3.org>

Hello All. Juan R wrote: > Whereas one can see an increasing interest in CSS, including printing of > books, there is not such one increasing in MathML. At contrary, apparently > nobody want print using MathML and there is a return to TeX bassed systems > (MathML to TeX conversors). This is false. Amongst professionals who deal with commercial publication of science, technical and medical material, the growth of MathML has been steady and marked. Based on Design Science sales records, MathML usage in large-scale publishing workflows has been increasing at around 100% a year for the last 3 or 4 years. This data is just as concrete as Ian Hutchinson's download logs. You can see a selection of some of the organizations using our tools for MathML in production at http://www.dessci.com/en/products/mathflow/mf_cust.htm. In many ways, our data likely gives a better indication of adoption within the industry than the data about TtM, as TtM is more focused on end user sales, and primarily end users in academia using TeX (where most TeX usage is) at that. Keep in mind that Prof Hutchinson is a physicist, who does TtM on the side as a hobby. By contrast, Design Science sales tend to be large, business-to-business sales to enterprise customers, with ongoing supprt. These are customers are typically making major investments to upgrade their publishing workflows to XML. They are overwhelmingly choosing MathML to represent mathematics. The are only a handful of large, serious publishing operations that have actually switched to XML for their production workflows that aren't using MathML, and even in those cases, it is mostly because of backwards compatibility, typically with TeX-based workflows, or in one or two cases, ISO12083 math. It is easy to understand how you would be unaware of what is going on amongst commercial STM publishers, and indeed, their requirements are very different from those of the amateur or academic individual wishing to hand author web pages for consumption of other similar individuals. I understand perfectly why you are frustrated about the difficulty of authoring and viewing math in your canoncial science web pages, and why this skews your viewpoint. However, from the point of view of professionals who make their living from STM publishing, display in web pages is merely one facet, and generally not a very critical facet, of what they need to produce from their source documents. Most of the commercial and enterprise customers we work with place strong emphasis on storing as much information as possible in their source documents, to maximize their options going into the future. They also prefer mature, standard solutions for which mature, supported tools exist and that integrate with the rest of their workflow software. The central requirement is generally the need to produce high-quality print output via PDF. Many must deal with accessibility. Most are interested in better information retrieval options. Almost all of them need strong validation, and maximum flexibility in transforming data for a wide-range of applications, from online assessment to symbolic computation. Thus, from the point of view of your typical STM publisher, the whole subject of CSS styling of math markup of some kind for display in web browsers is just one aspect of a much bigger problem. If George (White Lynx) is able to get his XML-Maiden stuff to the point where it works really well on a variety of browsers, and it is reasonably stable and well supported, that would be interesting. It would be one of many output formats that would then be possible options for web display, along with PDF, HTML+images, jsMath, AsciiMathML and the rest. Some, maybe even many, serious content providers would start using it. You have implied many times that advocates of MathML aren't interested in using CSS to render mathematics in web pages. But that isn't true. David Carlisle was blazing the trail in this area long before you and George got involved with it. Before that, the Microsoft representative to a previous Math Working Group went to the lengths of hiring a consultant to look into the feasibility of render math using CSS and JavaScript in IE5. We have worked closely with the CSS Working Groups over a period of many years to improve the capabilities of CSS to render mathematics, have on two separate occasions developed concrete and detailed proposals. Similarly, we have worked with the SVG people to investigate the options for math rendering in browsers, and diligently investigated other attempts in this area such as jsMath and ASCII MathML. But, it is huge leap to claim that XML plus CSS could replace MathML. Until you can offer the industry a standardized markup language, with multiple vendors of production capable tools, you don't have a viable alternative to MathML. Until you can demonstrate accessibility, online assessment, and symbolic computation, you don't have a viable alternative to MathML. Until you can demonstrate the ability to produce a variety of output formats from a single source, including professional print-quality output that can be easily integrated into current production workflows as well as HTML and XTHML output, you don't have a viable alternative to MathML. As I have pointed out consistently and repeatedly, your view of the requirements for a math markup language are entirely too narrow. XML + CSS solutions for rendering math in web browsers have their place as an output format. But it simply isn't a serious contender for meeting the broader requirements for a math markup language, as they actually exist in the world as opposed to within the limited scope of your canonical science project. If you want to work -- really work -- on improving XML + CSS rendering of math, then start doing it. There is plenty substantive technical discussion taking place on the subject on this list. Go ahead and work on really good rendering of scripts and stretchy fences, and all the other problems. When there just isn't a way to do something well today, figure out what changes it would take to CSS and we'll help you take that to the CSS WG. As you know, the Math WG and the CSS WG share the same W3C staff contact, Bert Bos, so it isn't like we don't talk to each other. If you succeed, XML+CSS will inevitably become more important relative to MathML, and you will achieve your goal more effectively than any number of postings bashing MathML will ever accomplish. --Robert Robert Miner Director, New Product Development Design Science, Inc. 140 Pine Avenue, 4th Floor Long Beach, California 90802 USA Tel: (651) 223-2883 Fax: (651) 292-0014 robertm@dessci.com www.dessci.com ~ Makers of MathType, MathFlow, MathPlayer, WebEQ, Equation Editor, TexAide ~ > -----Original Message----- > From: www-math-request@w3.org > [mailto:www-math-request@w3.org] On Behalf Of > juanrgonzaleza@canonicalscience.com > Sent: Friday, July 14, 2006 9:00 AM > To: www-math@w3.org > Subject: Re: Math on the web without MathML (CSS 2.1 > rendering for HTML and XML) > > > Patrick Ion said: > > > > Dear Juan, > > > > I certainly don't quarrel either with the quotation from > Hutchinson of > > <blockquote> > > MathML has a number of weaknesses. > > </blockquote> > > or, in fact, with the assertion. Nor is there a problem > for me with his > > <blockquote> > > My guess is that it won't. But with luck it will gradually > become more > > widespread. > > </blockquote> > > That's his prognosis and a benevolent wish. > > But apparently Hutchinson based his guess in three main > points: i) Server > statistics over last 5 years with its TtH and TtM, ii) Technical > (annoyances) issues of MathML, iii) History of the > mathematical markup. > > Whereas similar claims from MathML folks (waiting magical > spread of MathML > on the Internet) appear to be based in faith. > > > I could quibble over how > > big a niche might be, but I am not clear how MathML could > > 'take over web mathematics publishing' at the present stage of > > web technology. I'm not sure CSS has correspondingly taken > > over web page styling, though it's a lot wider in scope than > > MathML as a markup. > > Whereas one can see an increasing interest in CSS, including > printing of > books, there is not such one increasing in MathML. At > contrary, apparently > nobody want print using MathML and there is a return to TeX > bassed systems > (MathML to TeX conversors). > > E.g. last MSIE adds a better support for CSS, whereas > continues ignoring > MathML native support. > > > Where I questioned the attribution to Hutchinson was for > > the phrasing > > > >> we abandon the MathML approach, encourage to all us users, > >> collaborators, and visitors to abandon MathML, > > > > but I now see that perhaps you intended to convey in > > http://lists.w3.org/Archives/Public/www-math/2006Jul/0028.html > > not that sense of attribution to IH, but that you wished to > correct your > > typo by > > us users ==> our users > > Now I understand the confusion. I thought that was clear that > I was using > <blockquote> for Hutchinson's words. > > > So the syntax form of your message was, in outline, > > > > Typos ... > > > A > > may read > > B > > with > > C > > instead > > >D > > > > and might have been in another notation > > > > Typos: > > A ==> B > > D ==> C > > > > This perhaps illustrates the difficulties of markup without > > specifications. > > Maybe we would use content MathML 2.0 and prefix notation for > efficient > communication! > > > Are you really proposing to explore examples such as > > you have in > > > >> For instance, the recently > >> proposed at the HTML5 mailing list > >> <frac>a<den>2</frac> > >> also works with CSS, even if is *not* valid xml. Ok? > > No, it was an example of how the same CSS techniques can be reused in > HTML-XML-SGML (note that CSS-like techniques could be implemented in a > DSSSL engine thanks to similarity with XSL-FO). > > The point was that CSS techniques are more versatile than p-MathML. > > > Obviously one can work with other markup than valid XML. > > It just does not seem to me a very good idea in this > > context today. Any revision to a MathML spec will have to be > > consonant with other prevalent W3C specs, I believe, as the > > previous versions were at their times. > > Agree with requirement on consonancy with other specs but I > cannot agree > with the history. > > It would be not the first time is claimed that the MathML WG > reinvented > the wheel whereas ignored other specs. Hakon Wium Lie, from > w3c CSS WG, > wrote last month, > > <blockquote> > Historically, it's a common mistake to develop markup systems without > giving much thought to presentation. [...] Given that CSS existed when > MathML was created, I think the developers made a mistake by > not creating > a markup language that could be presented using existing CSS > properties. > </blockquote> > > > All the best, > > > > Patrick > > > Juan R. > > Center for CANONICAL |SCIENCE) > > > >Received on Friday, 14 July 2006 16:24:45 GMT

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