Re: The disappointment and embarrasment of MathML

Thomas,

Here are some comments on your message as well the paper you refer to at
http://www.dataweb.nl/~cool/Papers/MathML/OnMathML.html .

"You are probably under the impression that MathML is a good idea."

MathML is more than an idea. It has been formalized (specification) as well as 
realized (documents, software).

"It is Byzantinely complex, unintuitive, unesthetic, highly undocumented,
it requires complex software support, etcetera." 

What exactly is complex? [Re]presenting mathematical notation on the Web 
for subsequent actions is a nontrivial problem. Nontrivial problems can have 
nontrivial solutions. (Now, if only there were (on a 8 1/2 x 11 inch paper) a 
one-line proof of the Fermat's Last Theorem or one-line numerical solutions of 
bifurcation problems in nonlinear elliptic partial differential equations ...)

MathML is not designed (only) for aesthetics. Aesthetics in mathematical 
notation have no known bearing towards human understanding or machine-
based "intelligent" searching. Whether raw MathML is/is not "aesthetically 
pleasing" is subjective. The burden of aesthetics is on the processor at the 
delivery-end (renderer, printer). If needed, MathML can be transformed to 
"aesthetically pleasing" formats, including [La]TeX and/or PDF.

MathML is not "highly undocumented"; see the pointers at 
http://www.w3.org/Math/ .
In particular, (aging) http://indy.cs.concordia.ca/mathml/ and 
http://www.webeq.com provide documentation on various aspects of MathML.

"A quite perfect alternative already exists in Mathematica: simple, elegant, 
intuitive, highly documented etcetera - and users of Maple may think similarly 
about Maple."

1. Mathematica or Maple are not perfect alternatives to MathML. They
all serve different purposes (though overlap in intent) and are complementary.
This judgement is based on experience with all three, and not heuristics.
2. Mathematica and Maple are both proprietary solutions. MathML is not.
3. Simple, elegant, intuitive, ... are all subjective terms. Arbitrarily complex 
Mathematica or Maple programs can be written and so can MathML 
documents.

"The real reason why W3C developed MathML is ... (b) that they didn’t really 
deal with the makers of Mathematica(or Maple)."

Representatives from both Mathematica and Maple are (have been) on the
W3C Math WG.

"Scores of programmes have been written in Mathematica ... All that software 
becomes inaccessible in MathML - needs to be retranslated again etc."

1. Mathematica documents can be made available on the Web (via plug-in 
solution).
2. Mathematica 4 provides support for Mathematica document conversion 
(import/export) to MathML.

"W3C supposedly comes up with all kinds of subtleties. But it appears that 
such issues, and even more, already have been covered in Mathematica. 
They ‘only develop a standard’ and other - commercial ? - institutions will need 
to provide the real services."

W3C has developed:

1. Amaya, which provides rendering for MathML Presentation Markup.
2. EzMath, which provides a plug-in and an editor for MathML Content Markup.

"The idea is that a user will not see the MathML input."

Why not? It can (and has) been done. Use, for example, Form + 
CGI/[Programming Language of Choice] + MathML-aware parser.

"Please, if Mathematica can read "(a + b)^2", why should MathML make it so 
difficult ?!"

MathML is based on XML syntax. This can (but not always) lead to verbosity. 
This is an issue but there are several benefits (such as, more precise 
resource discovery) as trade-offs that outweigh that. It, however, remains an 
issue (typing errors, "too much" markup for "too little" result) if you insist on 
text-oriented editing (such as, via Emacs). Whether mathematical notations 
should be based on XML or whether embedded markup is the right direction, 
is an entirely different issue. See http://www.xml.com/pub/w3j/s3.nelson.html .

"What will put the horse behind the cart is that MathML creates the illusion that 
mathematics as a language is copyrighted - as the language for example is 
used in Mathematica."

There is no illusion. MathML Specification, like all W3C technical reports, 
explicitly state legalities surrounding it. See, for example, 
http://www.w3.org/Consortium/Legal/ipr-notice . 

"In the short run, MathML should be reduced to the statement <mathematics 
use=...> ... </mathematics> and the browser should have to capacity to call 
onto the computer language package."

MathML (and other external) objects can be incorporated in XHTML via the 
object tag. However, this plug-in/helper application view has several (by now, 
well-known) limitations. 

"... An ANSI standard should be developed that takes its point of reference in 
the history of mathematics and not in commercial developments of the last 10 
years."

MathML Specification takes into account and makes several references to 
mathematical development that go beyond the last 10 years. See, for example, 
http://www.w3.org/TR/MathML2/appendixi.html . 

The power of MathML comes from several sources, including:

1. MathML is an open, extensible format that leverages on other (open) 
standards. Nobody "owns" SGML, XML or MathML.
2. Based on XML syntax, as well as with the induction of semantics for both 
presentation and content MathML provides data (machine-to-machine 
interface) and as well as document view (human-to-machine 
interface) of the same MathML file, MathML record in a relational database, 
MathML object delivered by an Object Request Broker, and a MathML stream 
of bytes arriving at a network socket. Since the structure is separated from 
presentation, you can author MathML once, and use it in various contexts: 
present it (using CSS, XSL) on different devices (on desktop, PDA), 
manipulate/interact with it (using Computer Algebra Systems, DOM, XSLT), 
print it (by MathML -> PDF), exchange it between two MathML-aware servers.

In conclusion, MathML related issues remain (and are being addressed, within 
or outside the scope of MathML Specification), including: 

1. A robust infrastructure for large-scale, transparent (minimal, ideally zero 
loss of information) and automated (such as, by batch processing) legacy 
(say, [La]TeX, RTF) document transformation to MathML Content Markup.
2. Native rendering support in "popular" user agents to ensure a broad 
accessibility of MathML.
3. Mathematics-specific metadata that conforms with RDF Schema and takes 
into account existing metadata efforts (such as, Dublin Core, IMS metadata).
4. A stable list of MathML Content Markup elements that addresses 
localization. (It takes into account basic and widely-used mathematical 
notations used around the world (and not just those in USA or Europe.)
5. Semantic bindings for representing mathematical notations within the XML 
architecture that are external to the list of MathML Content Markup elements 
as well as external to OpenMathML CDs.

A (constructive) criticism is useful but your work, unfortunately, misrepresents 
the capabilities of both MathML and Mathematica (as well as, other Computer 
Algebra Systems), and does not address the essence of the issue well.

The horse is in front of the cart and galloping.

Pankaj Kamthan

P.S. There are typographical and grammatical errors in the paper. Examples: 
unesthetic, WC3.

Received on Thursday, 13 April 2000 20:41:50 UTC