From: David Carlisle <davidc@nag.co.uk>

Date: Wed, 12 Apr 2006 14:24:12 +0100

Message-Id: <200604121324.k3CDOCJL007100@edinburgh.nag.co.uk>

To: whitelynx@operamail.com

CC: www-math@w3.org

Date: Wed, 12 Apr 2006 14:24:12 +0100

Message-Id: <200604121324.k3CDOCJL007100@edinburgh.nag.co.uk>

To: whitelynx@operamail.com

CC: www-math@w3.org

> If someone could tell me where these millions of pages using MathML reside, it would simplify testing process a lot. I don't know where they all are, but there are several hundred documents here http://www.nag.com/numeric/CL/CLdocumentation.asp > Authoring tool makers constitute the only part of MathML community > that could be happy with artificially bloated syntax. Markup that being unreadable and > unprocessable by humans, forces people to buy WYSIWYG toys, is perfect solution > for commercial software makers, who if I am not mistaken played crusial role in making > "political decision" that resulted current MathML syntax. For what it's worth none of the MathML expressions in the documents on the NAG site have been processed by a WYSIWIG editor. Most of the older ones were converted from TeX, and current maintenance and new authoring is done directly in a more or less mathml syntax directly in emacs. The extensions from mathml used internally mainly relate to content mathml rather than presentation, as the set of empty elements designed for common "K-12 functions" doesn't really apply to the functions in our library, and it's just more convenient to use <apply><Ai/> than <apply><csymbol>Ai</csymbol> but this shorthand is easily expanded as part of the general transformation from our in-house DTD to XHTML+MathML. Converting our in-house documents from SGML-with-TeX-math-fragments to XML-with-MathML-math-fragments was of course a lot of work, but has shown a lot of benefit, the mathematics is far more consistently marked up now (TeX is so forgiving to authors:-) and the documents can be far more easily re-purposed. Mathematical expressions originally just intended for documentation are now used in code generation. Rather than just documenting constraints on some parameter, we can generate the code that checks the constraint. Note this is far easier in MathML where every operator is explictly tagged than in some suggested alternatives that make far more use of inline untagged text. The implication that the Working Group (Currently Interest Group) is dominated by makers of Commercial Wysywig systems is simply false. I've hardly ever used a WYSYWYG System and certainly have never written one. The Working Group has always had strong representation from Universities, Math Societies and standards bodies, potential users of mathml documents, as well as Computer Algebra systems and yes, makers of commercial math editors. One of the main reasons that I originally got involved with this project was that I was interested in the possibilites that could be achieved by getting old TeX hackers like myself in the same room as people from Microsoft, Maple, Mathematica, AMS, Design Science (MathType), and many other interested organisations and companies and comming up with a syntax for mathematical expressions on which everyone could agree. (Which isn't of course the same as saying every member of the committee thought every aspect of MathML was perfect) > From the first glance it looks like I have to pay more for bandwidth > (MathML markup is several times heavier), Experience shows (despite your impressive efforts with CSS-only rendering) that people are and were not happy with the typesetting quality of such a mechanism and in practice if they don't use MathML they tend to use TeX generated bitmap images. You typically (but probably not always) _save_ space by switching from bitmap images to MathML. You certainly gain a lot in typesetting quality for both screen and print rendering from the browser. > If number of MathML content on web > will grow significantly it will be impossible to make drastical changes in MathML Mathematics in US Patent documents has been coded in MathML for some years (this was a very large number of documents growing at a very fast rate when I last heard the details some years back) http://www.mathmlconference.org/2000/Talks/karleen/ there are other similar large organisations (including NAG) with large numbers of MathML documents. Do you really think making incompatible changes to any language after 8 years public use is something to be considered lightly? Removing elements isn't really an option, if necessary, new features could be added and old ones "deprecated" but look at HTML, That's had deprecated elements for years and it's not clear if the experiment in html4 (copied into xhtml 1.0) of having parallel strict and transitional versions with and without the deprecated features was a success, or whether it just spread confusion. David ________________________________________________________________________ This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________Received on Wednesday, 12 April 2006 13:30:02 UTC

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