- From: Michael Kohlhase <m.kohlhase@jacobs-university.de>
- Date: Sun, 16 Sep 2007 06:00:41 +0200
- To: Bert Bos <bert@w3.org>
- CC: www-math@w3.org, max@berger.name
Bert Bos wrote: > > Robert Miner wrote: >> I also support this. I don't think it will be controversial. > > Well... > > If we want MathML2 and 3 to co-exist (rather than recommend everybody to > upgrade to 3) and the two versions require different implementations, > then the difference should be expressed in the MIME type, by means of a > new identifier or a parameter. Otherwise the client cannot tell the > server what it supports and the server cannot give the client what it > needs. I am not sure that this even applies to MathML practice, since almost always will MathML exist as MathML islands in another XML application. So are you suggesting something like application/xhtml1.1+mathml3+svg2.1 ? I think that a version attribute in the source makes sense, since then applications can tailor the behavior to old versions, somewhat like quirks mode in browsers. Michael > > Even if the server only has one version of the document, it would be > wasteful to send it to a client that in the end cannot handle it. > > Also, we have to see what existing version-2 clients do with a version > attribute. If they don't stop on seeing the attribute but continue > parsing anyway, the attribute has no use. > > Probably, there are also quite a few documents that would be valid in > both MathML2 and MathML3, apart from that version attribute. The version > attribute would require you to make one file for old clients and another > for new ones. Keeping the version information outside the document > avoids that. > > In general, version information (in whatever form) embedded in the > document itself is not useful on the Web. Either the format has built-in > forward and backward compatibility (old implementations can do something > useful with new documents and vice versa), or it is in fact two > different formats and their identifiers should be available as MIME > types outside the document. > > HTML has long hesitated over this. The official specification has until > now had version information in the document, but implementations ignored > it. HTML5 therefore looks set to abandon the version info. > > CSS has never had version information and has always tried to be > forwards and backwards compatible. Sometimes people ask for version > information, but when questioned, it always turns out that what they > really mean is a way to target a particular browser. Version info > wouldn't help, because there is no specification that corresponds to a > particular browser, if only because there is no specification that > describes the bugs in browsers. > > (There is one counter-argument against new MIME types and that is that > authors sometimes don't have control over the MIME types of their Web > server, because their ISP is of too low quality. Some browsers therefore > don't rely on the lesser known MIME types, but instead use content > sniffing for commonly mislabeled types, i.e., they download the document > and try to guess its type from the content.) > > I haven't made a list of the changes between version 2 and 3, but I'm > hoping that we can avoid removing features (except for any that never > worked in the first place) and can thus keep all existing MathML > documents valid in version 3. The version 2 spec can then be declared > obsolete and all software has to be upgraded, but all content can remain > unchanged. There is more content than software and software has to be > updated regularly anyway. There is no need for a new MIME type or a > version parameter then. > > > > Bert -- ---------------------------------------------------------------------- Prof. Dr. Michael Kohlhase, Office: Research 1, Room 62 Professor of Computer Science Campus Ring 12, School of Engineering & Science D-28759 Bremen, Germany Jacobs University Bremen* tel/fax: +49 421 200-3140/-493140 m.kohlhase@jacobs-university.de http://kwarc.info/kohlhase skype: m.kohlhase * International University Bremen until Feb. 2007 ----------------------------------------------------------------------
Received on Sunday, 16 September 2007 04:01:04 UTC