- From: Tim Bagot <tsb-w3-math-0002@earth.li>
- Date: Tue, 22 Oct 2002 20:12:15 +0000 (UTC)
- To: <www-math@w3.org>
At 2002-10-22T07:28-0400, Ka-Ping Yee wrote:- > 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. In principle, one could also use content negotiation to make MathML documents available in other formats transparently (generated manually or automatically). Conversely, MathML may now be a useful output format for MINSE. > 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. True, but only an issue under the assumption that everything must be editable "by hand", i.e. as plain text. Why not use a dedicated maths editor for editing maths? In an ideal world, an HTML (or whatever) editor would seamlessly invoke the user's choice of mathematical editor. I'd be quite surprised by anyone complaining that they can't sensibly edit non-trivial SVG images with a text editor. > 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. Presentation MathML is already adequate for the vast majority of mathematics. You'll only run into problems if you're using unusual glyphs and/or layout. Server-side rendering will, of course, always win in this respect. With MathML, I suppose you could hack odd bits up with embedded SVG, but that won't help non-graphical readers. Content markup is inevitably more of a problem - but here the comparison with MINSE falls down, since: either MINSE serves only presentation; or semantically rich content can be provided, for which client software would need updating just the same. There is definitionURL; it's not nice, but it's better than nothing. > 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.) It's not that it can't be taught - it's that its verbosity will deter people from using it directly, and therefore they will not want to learn it. (Splitting of hairs there, perhaps, but MathML is certainly simple enough that learning it if you do want to is not particularly onerous.) I agree that this is unfortunate in some ways, but the aim has always been that authors should not have to be exposed to MathML. > You won't be able to communicate with > other people about how to write MathML if they use different > editing software. You won't be able to communicate with other people about how to write English 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. Again, the same is true of plain text. This is an excellent argument for open formats (so you do have a choice of software) and open source (so that you aren't reliant on the original software authors for the continued availability and useability of a particular editor). > 4. You still can't be sure you're getting semantics in MathML. > You might get semantics, presentation, or a mixture of both. True. You might even be getting an /inconsistent/ mixture. I suppose we just have to trust the author to act wisely. In some cases content markup is unlikely to be useful to anyone; in others content markup alone will be sufficent, and presentation markup redundant; sometimes content markup will be useful but not powerful enough by itself to encode the full semantics, or the author may feel the use of a particular presentation is significant. > 5. You still won't be able to send MathML in e-mail. If you can send HTML in email, you can send MathML.... This isn't /automatically/ bad. There's nothing inherently wrong with using something other than plain text for the body of an email, *if* it's the most appropriate format (and you have a reasonable suspicion that the recipient will be able to view it). Often it will suffice to cut and paste a textual representation from a MathML editor. MINSE does have the advantage that it remains fairly human-readable without a specialised viewer, while permitting enhanced presentation with minimal increase in bandwidth usage. > You still > won't be able to enter MathML into a form field. But you can > do both easily with MINSE. This too is not a design deficiency. There's no reason a browser could not open an editor session for a file upload control (especially if the desired content type has been specified). > 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. Like (2), another area where server-side will always win. (It restricts what you can use for the server, but that's a problem for fewer people.) The same is true of HTML though; the only real issue is that it might not be feasible (technologically or economically) to implement MathML support on small devices. With any luck, available processing power will keep growing for a while yet, and many of the problems will disappear.... Meanwhile, I suppose the answer in such situations is indeed transcoding proxies. Tim Bagot
Received on Tuesday, 22 October 2002 16:12:44 UTC