W3C home > Mailing lists > Public > www-math@w3.org > October 2002

Re: HOWTO implement cross-browser-compatible MathML

From: Robert Miner <RobertM@dessci.com>
Date: Mon, 21 Oct 2002 12:32:31 -0500
Message-Id: <200210211732.MAA07411@wisdom.geomtech.com>
To: ping@zesty.ca
CC: www-math@w3.org


> Ka-Ping Yee wrote:
> > MINSE enabled all of these user agents and more, including text-mode
> > browsers, on all platforms, to display math six years ago (and today),
> > without authors having to jump through the hoops necessary to get MathML
> > to appear in just the particular browsers and configurations you listed.
> Robert Miner replied:
> > Sure, and imaged-based documents created with MathType, latex2html or
> > Photoshop for that matter are also viewable in virtually any browser.
> 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.

It is important to separate the encoding from the deployment
strategy.  Of course you are correct that the MINSE encoding is

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.

> > But to use MINSE for image generation, as opposed to a
> > widely-deployed, well-supported, and easy-to-use tool like MathType,
> > your authors had to use your proprietary pseudo-semantic markup,
> It is interesting that you use "proprietary" like a bad word.  MINSE
> is not proprietary at all: it is not protected intellectual property,
> and it is neither for profit nor even associated with any company.
> MathType is a very nice program, but it isn't accessible to everyone --
> both because it is platform-limited and because it is a commercial
> (or should we say "proprietary") product that people have to buy.
> It is also interesting that you mention "pseudo-semantic markup".
> MINSE is a semantic language -- there's nothing "pseudo" about it.
> On the other hand, your disparaging term is more applicable to MathML,
> which could be called "pseudo-semantic" because it allows both content
> and presentation forms.  When one comes upon a piece of MathML, one
> may discover that it is actually semantic, or non-semantic, or some
> mixture of both (with complex rules for what kinds of mixing are
> allowed or forbidden).  The existence of these two separate forms of
> MathML only complicates the authoring and viewing process for everyone.

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.

Also, I looked at your site again, and "pseudo-semantic" is also
unjustified.  I have remembered that the style transformations were
defined inline within the structured expressions, but if I understand
what you have written on your site correctly, that isn't the case --
you have a clean separation of structure and style.  Of course, you
also invented your own styling language, so it is also open to the
criticism of being non-standard.

> > routing all their web traffic through a 'polymediator' server not
> > under their control, and give up on compatibility with other Web
> > stabdards such as XML, XSL, DOM, and CSS.  Those are substantial
> > drawbacks.
> The simple fact is that MINSE works.

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.  

In fact this has been done in a number of cases, and not merely with
MathML but TeX and other markup languages as well.  However, in spite
of their advantages, polymediators also have a number of severe
drawbacks, which has limited their usefulness on the web.  These include

- they only apply to online documents; they are useless to a computer
  not on the net, or with a slow connection

- they are really only useful for static web pages.  They are
  incompatible with client-side scripting, and of course, they are
  totally useless for math in other applications, say a publishing
  workflow based on DocBook.

- as David Carlisle has pointed out, by the time the document reaches
  the client, all the structure is gone.

- They don't scale well, and they are problematic for mission critical
  applications where a content provider may not want to be dependent
  on a third party server

> Despite much more time and effort invested, MathML only somewhat works.
> What you call "compatibility" with XML, XSL, DOM, and CSS is actually
> a dependency on all of these standards, which results in susceptibility
> to bugs and variations in the implementations of all these standards
> in different programs on different platforms.  This is the root cause
> of the MathML problems that Eugene Pivovarov is experiencing.

Sure.  But if we separate encoding from polymediation, MINSE works not
at all in browsers.

The difference between "compatibility" and "dependency" is largely in
the eye of the beholder.  It is undoubtedly true that standards-based
solutions suffer problems arising from incomplete or buggy
implementation.  However, the benefits of standards-based solutions,
especially in the Web world, are not really very controversial

That is why we see MathML being used in distance learning
applications, incorporated into mainstream authoring tools, being
used in commercial publishing workflows, imported into other standard
DTDs, and, not least of all, built into browsers.

By contrast, MINSE remains an interesting experiment, whose web site
hasn't been updated since 1996.

> And that's rather sad.  It's just depressing to see people like Eugene
> suffering with complicated workarounds (and needing "miracles" bestowed
> by wizards like David) when there's a much easier way.

So build a MathML polymediator!


Robert Miner                                    RobertM@dessci.com
MathML 2.0 Specification Co-editor                    651-223-2883
Design Science, Inc.   "How Science Communicates"   www.dessci.com
Received on Monday, 21 October 2002 13:33:34 GMT

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