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