Re: Technical reasons for some options taken on design of MathML

> 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