Re: MathML and the Dream of Math on the Web

I wrote:
>    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.

Pavi Sandhu wrote:
> The above is not true. I know of at least one book dedicated to
> MathML - the one I wrote. It's called "The MathML Handbook" and is
> scheduled for publication next month.

Pavi is right: I neglected to say "for ordinary users".  That is,
the fundamental flaw I am getting at is that MathML is not designed
to be learned, read, written, or understood by ordinary people.
Of course books can exist that describe MathML, but the position
of the MathML designers is that most users will not read such books;
instead, users will use editing software.  Thus, the designers of
MathML envision the average user buying books on how to use MathType,
not books on how to write MathML.  This establishes a dependency on
the tool that is, as I said, analogous to having to teach Microsoft
Word classes instead of English classes in school.

Every time someone points out that MathML is complex and verbose, the
working group repeats this response.  For example, the following is
from Robert Miner and Jeff Schaeffer's "Gentle Introduction to MathML":

    MathML is a low-level format for describing mathematics as a
    basis for machine to machine communication.  MathML is not
    intended for editing by hand, but is for handling by specialized
    authoring tools such as equation editors, or for export to and
    from other math packages.

    (http://www.dessci.com/support/tutorials/mathml/default.stm)

This position can be summarized as:

    MathML is not designed to be used by people.

Think about that for a second.  This is a very profound statement,
and it's a bad way to begin a design process.

Robert Miner wrote:
> However, your original post boasted that MINSE was viewable in any
> browser and had been for years.  That claim was based on your
> deployment strategy of using a polymediator server to translate MINSE
> expressions into images.  Without those server-side produced images,
> your claim of browser accessibility is no longer true.

Robert's reply to "MINSE works" is "Ah, but if part of it didn't
exist, it wouldn't work."  That has no bearing on the fact that
MINSE works.  If Robert is allowed to assume false statements,
he can conclude anything he wants.

Robert Miner wrote:
> You are right -- I shouldn't have used the word "proprietary" which is
> incorrect.  "Non-standard" was what I was trying to get at.  How MINSE
> works is subject to your caprice.

And what a nasty, capricious devil I am!  I reject this use of
"non-standard" as an empty epithet -- it tries to sound as though
I will change MINSE here and there at my whim, dictating control
over hapless users of the language.  The picture is quite different
in reality: users actually have more control over MINSE than MathML,
because MINSE provides them with flexibility and extensibility that
MathML doesn't have.  On the other hand, users have very little
control over how MathML works, because any extra semantics they want
will have to be approved by a distant committee (then again, it
wasn't designed for them anyway, so why bother listening to them?).

Note also that criticizing something as "non-standard" isn't much
of an argument from someone on the committee that decided what was
going to be standard or non-standard.

Robert Miner wrote:
> Of course, you also invented your own styling language, so it is
> also open to the criticism of being non-standard.

The styling language is Python, which is much easier to read, write,
and understand than XSLT, more powerful than XSLT, more mature than
XSLT, and has vastly greater distribution, use, and mindshare than
XSLT.  (Making up new things and declaring them standard just in
order to poo-poo everything else as "non-standard" doesn't instantly
invalidate all the existing tools that have worked for years.  Here,
I'm drawing a distinction between "standard" == "approved by a distant
committee" and "standard" == "what lots of people actually know".)

Robert Miner wrote:
> Again, you confound your encoding with your deployment strategy.  The
> true statement is "polymediators work".  If you choose to set up a
> server to translate documents with embedded MathML into documents with
> embedded images, then MathML would work exactly as well as MINSE works
> according to your definition.

Again false.  Although a mediator would make MathML documents render
for more browsers, MathML would still be unreadable and unwritable by
normal people.

It is you who are confusing design and deployment.  As i tried to
explain in my last message, there are two distinct issues here:
(a) what's available today and (b) what's possible in the future.
As for (a), the fact is that a polymediator exists for MINSE and not
for MathML; therefore MINSE is more accessible than MathML today.
As for (b), MINSE will remain easier to read and write than MathML.

David Carlisle wrote:
> Basically yes it is easier. It is easier to use standard tools to
> manipulate the document (xslt for example) it's easier to make the
> document work offline (on CDROM, or on my laptop when its not plugged
> into the net) and its easier to make the final form look like
> an integerated part of the document rather than some collection of
> images.

I see three points here: (a) xslt, (b) offline use, and (c) rendering.
Aside from (b), what you're saying is that people have written more
software for MathML.  With that I have no argument; that is factually
true.  That's not the same as saying that it's easier to write MathML.

As for (b), if you're going to send somebody a CDROM, you can include
whatever software you want anyway.  If you're not, then for most people
using their current software, MathML works not at all, in which case
having something while you're online is better than having nothing.
I agree that saving a document for offline use (e.g. on your laptop)
works better with MathML than MINSE if you already have MathML working
on your machine.

It is entirely true that you can do more with MathML today, if you
have the right tools, because a lot more tools have been written
for MathML.  I am at fault for accepting the invitation to the W3C
Math Working Group, for allowing it to stonewall MINSE and convince
me that my work was pointless; I am at fault for not writing more
MINSE tools.  In a way I was selfish in that I chose to go on doing
other things in my own life instead of devoting myself to a mission
that would have made things better for everyone else.

David Carlisle wrote:
> If it [the MINSE polymediator] served mathml
> from the same input it would look a lot nicer, and all your arguments
> about the ease of authoring minse would be moot.

No -- in fact, it is MathML that would become moot, because you're
describing a world where people would be authoring MINSE instead
of MathML.  Actually, you have just made my point: what you just said
amounts to "MathML is a fine language, as long as you use MINSE".

I agree that a mediator for translating MINSE into MathML would be
a good step toward repairing some of the damage that MathML has done.
Unfortunately, when translating documents into MathML, it is likely
that some of the semantics will be irretrievably lost.  The more we
can move authors away from MathML, the better.


-- ?!ng

Received on Wednesday, 30 October 2002 07:03:31 UTC