W3C home > Mailing lists > Public > www-math@w3.org > May 2007

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

From: Richard Kaye <R.W.Kaye@bham.ac.uk>
Date: Wed, 30 May 2007 10:54:20 +0100 (BST)
Message-ID: <62023.80.195.165.6.1180518860.squirrel@web.mat.bham.ac.uk>
To: "Chris Chiasson" <chris@chiasson.name>
Cc: r.w.kaye@bham.ac.uk, www-math@w3.org

Thanks Chris. I didn't know about this!

I may be going off topic now... apologies if so.

I guess what is being tested in http://jigsaw.w3.org/HTTP/CL/
is a relative link which should be relative to the Content-Location
header when present, but is in most browsers is relative to the actual
URI. All the browsers I have right now (IE7, Firefox 2.0.0.3, and an
older mozilla clone) return the same result on this test: "Your
browser does NOT compute the base URI of the document per Section 14.14
of rfc2616", presumably meaning that they don't conform to this
slightly obscure test.

What I was suspecting in my earler post is that IE is doing
mime-type sniffing based on the Content-Location header. I really
don't see how to set up a test for this at the server end.

Richard


> There are demo pages on the internet that can test (some aspects of)
> whether or not the browser is using the content-location header.
>
> For instance:
> http://jigsaw.w3.org/HTTP/CL/
>
> On 5/29/07, Richard Kaye <R.W.Kaye@bham.ac.uk> wrote:
>>
>> 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-----
>> >
>> >
>>
>>
>>
>
>
> --
> http://chris.chiasson.name/
>
Received on Wednesday, 30 May 2007 09:55:00 GMT

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