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

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

Date: Tue, 22 Oct 2002 07:28:36 -0400 (EDT)

To: David Carlisle <davidc@nag.co.uk>

Cc: www-math@w3.org

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

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.htmReceived on Tuesday, 22 October 2002 08:02:32 GMT

*
This archive was generated by hypermail 2.2.0+W3C-0.50
: Saturday, 20 February 2010 06:12:51 GMT
*