RE: MathML won't display (or: what triggers mathplayer behaviour?)

Dear all

I have made a few small discoveries.

Most importantly, that the mimetypes text/xml and 
application/xhtml+xml behave quite differently in 
IE7 in at least two different ways.  

If I serve a document with extension .xml and
  Content-type: text/xml; charset=utf-8
then Mathplayer is triggered correctly provided
I have the appropriate key in ../PROTOCOLS/Filter/ 
with name "text/xml; charset=utf-8".  If the same
file is served with
  Content-type: text/xml;charset=utf-8
(no space) then all is OK but only provided I 
rename the registry key, removing the space.

Do the same for "application/xhtml+xml; charset=..." with a
file still with .xml extension and I get a readable
web page, but no MathML and MathPlayer is not started.
(that's even after checking all the registry keys etc
are correct). In all the experiments I have done, if the 
extension is .xhtml and there is a charset spec in the
Content-Type then the IE always displays the xml tree.

I was able to display MathML-enabled XHTML correctly, when 
served from a tomcat servlet (where there was no
file or file extension) but only after changing the
mimetype to "text/xml;charset=utf-8" and tweaking the
registry on the client accordingly.  I can't verify
Robert's idea that it is somehow the way the document is 
served, though clearly IE uses an extension (.xml, .xhtml)
if one is available.

So it seems to me that: (1) it seems that IE makes an effort to 
display html when the extension is ".xml" irrespective of 
the mimetype; and (2) fiddling with the registry keys works 
for text/xml but not for application/xhtml+xml. It's getting
late over here and I am tired.  I may be jumping to false
conclusions over here, so if you are interested you had better
double-check this yourself.

This does not yet provide me with a workaround for my blog
server since the Tomcat I have insists on removing the space
in the "; charset=..." even when I deliberately put it there,
and therefore a registry tweak would be needed on all 
client machines. (That's because MathPlayer installs with 
the "text/xml; charset=utf-8" key but not the
"text/xml;charset=utf-8" key. If only one is provided then that
is probably the right way round as my Apache actually inserts 
a space in ";charset=..." even when I deliberately omit it...)

A couple of other things: 

1. I did try the effect of adding a BOM a long time ago, with 
no effect on the documents giving me XML trees.  

2. I have also used URLs with no extension (the correct 
document provided by content negotiation) successfully before.  
I didn't think the client knew the full name of the file in 
such cases, but now I look at it I have noticed a 
  Content-Location: <filename>
HTTP header which might explain a lot.  Does IE use this?

3. I had never thought about using text/xml until now.  I seem to 
remember reading reasons why text/xml is a Bad Thing, but can't 
remember them. Anyone else know?

Richard


On Tue, 2007-05-29 at 08:48 -0700, Robert Miner wrote:
> Hi Jacques,
> 
> There isn't a direct connection between the charset and the XML tree.
> But just as IE doesn't seem to always follow the rules for determining
> the encoding, it also does not play by the rules for determining the
> MIME type (as I'm sure you know).  
> 
> The XML tree shows up when IE doesn't believe the http header's
> declaration that the MIME type is application/xhtml+xml and doesn't
> start up MathPlayer.  Somewhere later on, it must realize the document
> is XML at least, since it displays the tree.  But at the point it is
> supposed to invoke MathPlayer if the MIME type is application/xhtml+xml,
> the call never comes, at least as far as I can determine by setting a
> breakpoint in the relevant routine in the debugger.
> 
> We had been experimenting with the charset parameter, on the hypothesis
> that somehow that might be preventing IE from recognizing the MIME
> declaration in the http header. But it doesn't seem to.  Mostly it seems
> like if the document is dynamically generated, so there isn't a file
> name in the http header, IE just sniffs the content and get's it wrong
> for purposes of firing off MathPlayer.  At least that is what the
> experimental evidence seems to suggest to me.
> 
> I thought perhaps Richard's comment about the BOM meant that if there
> was a BOM, suddenly IE's sniffer did the right thing and recognized the
> content as application/xhtml+xml and fired up MathPlayer.  But I guess
> not.
> 
> --Robert
> 
> Robert Miner
> Director, New Product Development
> 
> Design Science, Inc.
> 140 Pine Avenue, 4th Floor
> Long Beach, California  90802
> USA
> Tel:  (651) 223-2883
> Fax:  (651) 292-0014
> robertm@dessci.com
> www.dessci.com
> ~ Makers of MathType, MathFlow, MathPlayer, WebEQ, Equation Editor,
> TexAide ~
> 
> 
> > -----Original Message-----
> > From: Jacques Distler [mailto:distler@golem.ph.utexas.edu]
> > Sent: Tuesday, May 29, 2007 10:19 AM
> > To: Robert Miner
> > Cc: R.W.Kaye@bham.ac.uk; www-math@w3.org; William F. Hammond
> > Subject: Re: MathML won't display (or: what triggers mathplayer
> > behaviour?)
> > 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > 
> > On May 29, 2007, at 9:33 AM, Robert Miner wrote:
> > 
> > > So does the byte order mark solve the problem in all the situations
> > > you know of?  It would be great if it really was that simple?
> > 
> > Depends on what "the problem" is.
> > 
> > MSIE (both 6 and 7) does not, under some circumstances, respect the
> > established rules for setting the encoding of the document. Instead,
> > it tries to sniff the encoding, a procedure that probably does not
> > play well with the MathPlayer plugin. See, e.g. this discussion:
> > 
> >      http://annevankesteren.nl/2005/02/charset#comment-3167
> > 
> > That, as far as I can tell, does not have anything to do with the "IE7
> > +MathPlayer shows an XML document tree"  problem.
> > 
> > Or, if it does, no one has explained the connection to me.
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.3 (Darwin)
> > Comment: PGP Key - http://golem.ph.utexas.edu/~distler/distler.asc
> > 
> > iD8DBQFGXERwnyqPIXpYcjcRAhfDAKCSA4L/MunLbgzFDUoTpsLzJJV5KACgy1oS
> > UqriwBgMkVIKJZx8J17n5zA=
> > =lDK+
> > -----END PGP SIGNATURE-----
> 
>

Received on Tuesday, 29 May 2007 18:23:15 UTC