[Prev][Next][Index][Thread]
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.