- From: Ka-Ping Yee <ping@zesty.ca>
- Date: Tue, 22 Oct 2002 07:28:36 -0400 (EDT)
- To: David Carlisle <davidc@nag.co.uk>
- Cc: www-math@w3.org
Before I proceed with a reply to David's comments, please let me
explain something. It's the important point, so it comes first.
Why am I raising these frustrations with MathML in a public forum?
Because I see a dream being forgotten. I would not be so compelled
to speak up if it were only me suffering because of MathML. But it's
more serious than that: *everyone* suffers. And the ones who suffer
most are the ones that need it the most.
The Web is the great equalizer of our day. It puts the power of
worldwide publication in the hands of the common citizen. It used
to be the case that only monks knew how to read and write; then the
printing press brought literacy to the populace. Soon everyone had
books, but for a while, publishing remained an expensive and
complicated endeavour, reserved for those who had the specialized
knowledge and equipment necessary to print books. The Web brought
nothing less than a revolution in personal expression: now ordinary
people can publish to the whole world almost for free.
Part of the reason this was so successful is that HTML was dead
simple. You didn't have to have a degree to write HTML; you could
pick up the basics in five minutes. Devoted Web-heads could argue
about whether it was better to use <B> or <STRONG>, but most people
could ignore them and their pages would still *work* anyway. Even
though HTML is messy, the most significant bit is that it did satisfy
the basic needs of just about everyone. Today, just like ten years
ago, anyone can still open a text editor and write a simple HTML
document in 30 seconds.
Back in 1996, when I realized that it would be useful to put math
into Web documents, and saw a way to do it, I was excited because
of a dream -- a dream I know many of you shared at that time, too.
The dream was that, one day, you would be able to express math in Web
documents about as easily as text, and that it would be simple enough
to read and write for anyone who understood math. And I mean everyone:
young, old, rich, poor, elementary or graduate student, schoolteacher,
professor, sighted, blind, and so on. It had to just *work* the way
HTML (mostly) just worked. Those were the primary motivations that
led me to design MINSE the way it was designed.
But what do we have now? I see a group of technically sophisticated
academics who have forgotten that mathematics should be for everyone.
Yes, everyone -- not just math professors.
MathML is not going to help teach numeracy to fifth-graders. It is
not going to help students in developing countries learn economics.
It's not going to help an activist explain to her fellow citizens
why they should vote for a new financial initiative. It's not even
likely to help most undergraduates submit their calculus assignments
online. MathML is too hard. (I mean both that it's hard to write,
and hard to make it work.)
There is an unfortunate trend in Web standards these days. The
standards are growing more numerous, more complicated, more
interdependent, and more removed from the needs of real people.
MathML is part of that trend. It reserves mathematics as a domain
for the elite: to write math you must be patient enough to study and
understand not just MathML but also the other standards it depends on,
as well as the idiosyncrasies of the various browsers and plug-ins
you want to support. "View Source" isn't going to help you anymore,
because the page you're looking at might not target the same client.
At least for now, the compatibility issues make MathML a write-once,
test-everywhere experience. With HTML, sure, there were some
incompatibilities when tables were first introduced, but basic
stuff would always work. With MathML, you can't even get *started*
until you've decided whether to use presentation or content markup,
and chosen which browser/platform/plug-in combinations you're going
to support. All this puts MathML in the domain of wizards.
What happened to the dream? It's been left behind. Many people
probably haven't even considered the possibility that they might
put math on the Web (just as many people didn't imagine they could
publish on a worldwide scale before the Web existed). The ones
who are brave enough to look at MathML will quickly have their
suspicions confirmed that -- indeed -- math on the Web is only for
experts, and much too advanced a topic for mere mortals.
That is why I have to say something. People should know that math
on the Web can be for them, not just for Web experts. They should
know that using math doesn't require committing their documents to
the realm of untouchable code that isn't supposed to be read or
understood or fixed. They should know that using math doesn't *have*
to be that hard, even if MathML makes it seem that way.
Think of all those people out there that might benefit from having
math on the Web, but won't even know it -- because they won't try.
To those people out there I say: don't let MathML destroy the dream.
The dream can be real.
And now, on with details.
On Fri, 18 Oct 2002, David Carlisle wrote:
> > You have forgotten that MINSE expressions are medium-independent
> > (it's right there in the first two letters of the acronym "MINSE").
> > Although images are one target, they are not the only possible target.
>
> but the point is that if the server desides to send you an image then
> that is what you get on the client and so the structure is hidden.
> and so minse in this respect is no different from any other server side
> generation of the mathematics images from other sources
[...]
> I'm not sure it's easier, also the end result is undoubtably worse. that
> isn't a fault of your minse system as such it is just a feature of using
> images in a browser
Certainly I agree that it is better to have mathematics understood
by the client than to only have images. But when you draw
comparisons, please be careful to choose fair parallels to compare.
The issues with these systems can be broadly divided into two
categories: implementation issues (fixable) and design issues
(practically unfixable). Let's be careful not to assume a world
in which MathML implementations can be fixed and MINSE cannot, or
where MINSE implementations can be fixed and MathML ones cannot.
I actually believe that MINSE is better from both perspectives.
That is, (a) its implementation six years ago better served the needs
of most people than MathML does today; and (b) in a future where
implementations of MINSE and MathML are both ideal, MINSE would still
serve the needs of most people better than MathML would.
Implementation:
1. "MINSE is no different from other server-side image generation"
That's not really true. With other systems (e.g. LaTeX2HTML)
the original document is converted and saved in a new form
containing images, which then gets posted on the Web. The
semantics are unrecoverable from the Web version. Of course,
you can keep around the original document, but then you have
two versions to maintain, and your readers still don't have a
way to get at the semantics unless you also offer them the
original document, which defeats the whole point.
With MINSE the document is saved in only one form, the semantic
form. The client gets to ask for whatever rendered form it wants.
The document posted on the Web is the original, the "one true
version", containing the original semantics.
2. "the end result [a document with images] is undoubtably worse"
To a browser that understands math semantics and is capable of
rendering math nicely, obviously an image alone is worse than
semantics alone. To the 99% of existing browsers that understand
images but not math, the semantics don't make any difference;
the image is what counts. Ah, but you say, it's important to be
*able* to get the semantics if you really want them. Agreed,
and so you can -- just fetch the original document.
Okay, now there are programs other than browsers that understand
MathML -- like Mathematica. Indeed this is an advantage (though
it should be noted that it only exists because Mathematica chose
to accept MathML, not because of any property of MathML). I agree
that this is an important capability. But take a moment to consider
your target audience. I'll bet most of them just want to read the
math: as evidence, observe how many of them are happy with LaTeX.
Certainly they would much rather get an image than get nothing.
MINSE serves their needs, while also preserving semantics for other
purposes. In other words, the simple things are easy and the
complex things are possible. MathML is a case of making the
complex things possible at the expense of also making the simple
things very, very hard.
3. "not sure it's easier"
All right. I will try to convince you. Let's suppose I want to
write a page about the Pythagorean formula.
If I use MINSE, I write this:
<p>The hypotenuse of a right triangle can be found by:
<se> a = 'root(b^2 + c^2) </se>.
into an HTML document, include a link to minse.org, and I'm done.
If I use MathML, I have a few options:
(a) Understand MathML. Put the following in a document:
<p>The hypotenuse of a right triangle can be found by:
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mrow>
<mi>a</mi>
<mo>=</mo>
<msqrt>
<mrow>
<msup>
<mi>b</mi>
<mn>2</mn>
</msup>
<mo>+</mo>
<msup>
<mi>a</mi>
<mn>2</mn>
</msup>
</mrow>
</msqrt>
</mrow>
Hope that the person reading the document has IE 5.5
or higher, in which case ask them to install MathPlayer;
otherwise hope they are willing to install Mozilla or Amaya
in order to read my document.
(b) Understand MathML. Put the following in a document:
<p>The hypotenuse of a right triangle can be found by:
<math xmlns="http://www.w3.org/1998/Math/MathML">
<reln>
<eq/>
<ci>a</ci>
<apply>
<root/>
<apply>
<plus/>
<apply>
<power/>
<ci>b</ci>
<cn>2</cn>
</apply>
<apply>
<power/>
<ci>c</ci>
<cn>2</cn>
</apply>
</apply>
<cn>2</cn>
</apply>
</reln>
</math>
Hope that the person reading the document has IE 5.5
or higher, in which case ask them to install MathPlayer;
otherwise hope they are willing to install Mozilla or Amaya
in order to read my document.
(c) Find software to help me write MathML that runs on my
operating system. Let's suppose I get MathType. Start
MathType, type in the formula. Very easy.
Now, export the document. I have a few more choices:
i. Save as a GIF. Then upload the GIF separately and
reference it in an <img> element on my page. Then
remember to update my page whenever the GIF changes,
and to move the GIF whenever I move or copy the page.
ii. Understand that I can copy and paste MathML out of
MathType, as long as I set the right translator.
Go to Preferences -> Translators. Decide which of
the four available MathML translators to use.
Copy the expression. Paste it into my document.
Save my MathType file separately so I can go back and
edit it later. Maintain both the MathType file and
the MathML file.
Hope that the person reading the document has IE 5.5
or higher, in which case ask them to install MathPlayer;
otherwise hope they are willing to install Mozilla or
Amaya in order to read my document.
MathType gives me a third alternative: I can write my
document in MS Word. When I click "Insert Equation" it
launches MathType in a separate window, where I enter my
formula. Then I select "Export to MathPage". I have two
more choices:
i. Use GIF images. Maintain a pile of images along with
my document. Also, hope that the person reading my
document has Internet Explorer, because the fancy
equation layout doesn't work in Opera. MathZoom
doesn't work in Opera either.
(I have to say the claim that MathPage produces
"*stunningly* beautiful results" (emphasis theirs) is
highly overblown. It may be a bit nicer than what you get
from LaTeX2HTML, but it's quite crude next to the
pleasantly antialiased images you get from MINSE [1].
The subscripts on the demo page presented by MathType [2]
are unreadably small -- what's supposed to be a subscript
"s" on r_s, "radius of the smear", is only 3 pixels high!)
ii. Export to MathML. Decide which of the 10 different
translators to use. Save my Word file separately so
I can go back and edit it later. Maintain both the
Word file and the MathML file. Hope that the person
reading the document has a browser and plug-in
combination that works with the choices I made.
If I want the resulting MathML document to work both in
IE and Mozilla, I also have to do one of the following,
as discovered by Eugene:
1.
a. Convert all symbolic entities to the corresponding unicode
(e.g., 'ℏ' to 'ℏ').
b. Delete 'mml:' in all MathML commands and adjust the <html>
tag accordingly.
c. Correct <math> tags if they do not specify xmlns.
d. Add the reference to mathml.xsl or pmathml.xsl if missing.
e. Rename the file to *.xml, make it XML compliant (add <?xml>,
convert all tags to the lower case, etc.) and clean it up
(remove unnecessary <style>, <object> and <?import> tags, etc.)
2.
a. Combine xhtml-lat1.ent, xhtml-symbol.ent, xhtml-special.ent
and mmlalias.ent into a local DTD, say, math.dtd.
b. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML
2.0//EN" "math.dtd">
c. Add the reference to mathml.xsl if it is missing.
d. Same as 1e.
And that's not all. Keep in mind the time and expertise necessary
just to decide whether to go with (a), (b), or (c); and if (c), whether
to choose (i) or (ii), and whether I need to do Eugene's fixups.
Okay, what seems easier to you now? Are you convinced yet?
Design:
Now imagine an ideal world where MathML and MINSE viewers work reliably
on all the popular browsers. What differences remain?
1. You still can't easily edit MathML documents by hand. This
means you can't maintain your math documents the same way you
maintain other Web documents. You will have to get extra
software to help you edit MathML, and you probably won't be
able to use the same editors you normally do. Sometimes you
will still have to keep two copies of things.
2. You still can't extend MathML. The only way to get a new tag
into MathML is by passing a new specification through the W3C
process, and then waiting for all the browsers and plug-ins
to implement it in the next version, and then waiting some more
until all the incompatibilities dissipate. With MINSE, you
just update your stylesheet and supply the needed renderings.
As you share your extensions with your community, people settle
on common conventions and the language grows.
3. You still can't teach MathML. Books can't or won't explain how
to write MathML. Learning MathML will be specific to learning
how to use a particular editor. (This is analogous to being
unable to learn English; you can only choose to learn MS Word
or WordPerfect etc.) You won't be able to communicate with
other people about how to write MathML if they use different
editing software. And if the company making your editor goes
out of business, or the user interface of your editor changes
substantially, you'll have to relearn.
4. You still can't be sure you're getting semantics in MathML.
You might get semantics, presentation, or a mixture of both.
5. You still won't be able to send MathML in e-mail. You still
won't be able to enter MathML into a form field. But you can
do both easily with MINSE.
6. When a new platform appears (e.g. a new handheld computer),
you'll have to wait for a viewer and editor to be ported to it
before you can use MathML. But you can easily enter MINSE.
You can even read MINSE fairly easily without a viewer.
-- ?!ng
[1] http://minse.org/nph-pmpm.cgi/http://minse.org/example.html
[2] http://www.mathtype.com/features/samples/compare/mathpage.htm
Received on Tuesday, 22 October 2002 08:02:32 UTC