Re: XHTML2 MIME type

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Mikko,


Am Mittwoch, 9. April 2003 11:41 schrieb Mikko Rantalainen:
> Jim Dabell / 2003-04-08 20:29:
> If we get XHTML2 out relatively fast I don't see any problem with using
> application/xhtml+xml for it too. Though I'd rather use text/xhtml+xml.

My argument pro recycling application/xhtml+xml:
RFC 3236 denotes the possibility that application/xhtml+xml will be used for 
future versions of XHTML (while the RFC 2854 about text/html restricts its 
usage on HTML and XHTML 1.0).

I think it makes life a lot easier when application/xhtml+xml is used, since 
neither updates to existing RFCs nor new RFCs would be required.

Besides:
The advantage of application/xhtml+xml is that it is already registered as RFC 
3236 while the MIME Type text/xhtml+xml doesn't exist.

I am for keeping application/xhtml+xml because it is not very convenient to 
use mixed types with different base types. A mixed type mixing xhtml, svg, 
mathml and smil doesn't really belong to text/*.


> Rationale: only browsers that correctly send application/xhtml+xml with
> their content negotiation string are those based on gecko engine, AFAIK.
> Opera could follow soon. Any browser that doesn't even claim to support
> the type shouldn't be considered even though it really supported it. I
> believe that all gecko based browsers and Opera are going to support
> XHTML2 soon enough anyway. And it doesn't matter with older browsers
> because they don't know XHTML either.
I can confirm this:
* Gecko based ua's send application/xhtml+xml as part of their Accept header. 
Opera and Konqueror currently don't.
* My impression is that Gecko based, Opera and Konqueror will support XHTML 2 
quite soon.

> Yes, I also feel that every different file type should have different
> MIME type but I think not everybody thinks XHTML2 should use MIME type
> like application/x-html2-2003-4+xml. The rationale for such type would
> be that because we really don't know what XHTML2 turns to be, we
> shouldn't claim that we author according to it. We can claim that we
> author to it as we know it in April of 2003.

My argument contra recycling application/xhtml+xml:
I think the Namespace is a good indicator for wether a new MIME Type should be 
used. Covering XHTML and XHTML2 with the same MIME Type but a different 
Namespace will produce the following result:
A user agent sends Accept: application/xhtml+xml and receives XHTML2. It 
parses the XHTML2, detects that the Namespace is not supported and prints an 
error message. Not very convenient.

> Another way to think this: how about MIME type application/xhtml2
> (without the +xml part). This would be interpreted to contain all real
> types that are extensions of XHTML 2. Otherwise, we really should use
> MIME types like application/xhtml+mathml+svg and
> application/xhtml+svg+smil.

The +xml surely will stay.
It is an indicator for XML clients that don't know anything about the concrete 
XML based language so they know it's at least XML and could be processed by 
them. That's why it is application/xhtml+xml or image/svg+xml.

> Yet another idea: is it possible to add another base type to MIME types?
> It seems that XML is getting big enough that we could really use
> something like xml/xhtml2, xml/smil, xml/svg, xml/x-my-own-format.
I don't like the idea since xml isn't really a new base type while image, 
audio and text are.
Of course you may suggest this to the IETF.
But IMHO, this idea has no chance ;-)
At least not yet. Perhaps in some years, if XML becomes vital for the 
Internet, not just the WWW.


Bye
- -- 
ITCQIS GmbH
Christian Wolfgang Hujer
Geschäftsführender Gesellschafter
Telefon: +49  (0)89  27 37 04 37
Telefax: +49  (0)89  27 37 04 39
E-Mail: Christian.Hujer@itcqis.com
WWW: http://www.itcqis.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+k/fAzu6h7O/MKZkRAteyAJ4w2O6ymt/88I9fa9XQxbexPHLSvgCeL6BF
69plI/80ZUqJRDADskSJwDM=
=d6Lp
-----END PGP SIGNATURE-----

Received on Friday, 11 April 2003 00:06:02 UTC