From: Ka-Ping Yee <ping@zesty.ca>

Date: Wed, 30 Oct 2002 06:01:15 -0500 (EST)

To: Pavi Sandhu <pavi@wolfram.com>

Cc: www-math@w3.org

Message-ID: <Pine.LNX.4.44.0210231317420.22337-100000@ziggy>

Date: Wed, 30 Oct 2002 06:01:15 -0500 (EST)

To: Pavi Sandhu <pavi@wolfram.com>

Cc: www-math@w3.org

Message-ID: <Pine.LNX.4.44.0210231317420.22337-100000@ziggy>

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. -- ?!ngReceived on Wednesday, 30 October 2002 07:03:31 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 21:27:32 UTC
*