Re: [widgets] Content-type sniffing and file extension to MIME mapping

Marcos Caceres schreef:
> Moi? a personal political agenda to rid the word of
> application/xhtml+xml? never! :P
>   

^_^

> Seriously speaking, the list of types is supposed to reflect what the
> working group believes are the core development technologies that
> underpin widgets (for version 1.0, at least). I personally don't have
> an issue with including application/xhtml+xml, but I think it is
> unfair to require implementations to support it. Also, having optional
> supported types introduces fragmentation. However, we could add
> application/xhtml+xml and say that if the implementation does not
> handle xhtml, then it may treat it as text/html... but that is
> probably just asking for problems(?).

I see.

But, what I do not understand (hence also why I don’t really understand 
the objection against defining the mp3 and swf extensions…), why can you 
just not include a reasonably exhaustive list of specified extensions? 
Specifying a mapping from an extension to a MIME type does not mandate 
that format as a requirement for Widgets. Which formats are required for 
a Widgets implementation should be a separate concern.

Also, as a matter of fact, out of the four major browsers, three support 
application/xhtml+xml (Firefox, Safari, Opera), and who knows, by the 
time IE implements this they might have support for it as well. If it 
would take a new Widgets spec version to include XHTML, by the time IE 
implements the MIME type we would have to wait another couple of years 
before the new Widgets version adds the extension to its list and 
browsers implement that? Of course, browsers can add their own MIME 
types (according to your text in your 2008-12-3 23:03 message), but then 
you miss the benefit of standardisation and one browser might go for 
something silly like .xht instead of .xhtml :). Or maybe it turns out 
that there is a need for a .xht extension mapping as well (as all other 
extensions have a three-character version).

So, I see no real reason to exclude XHTML from the list. The Widgets 
specification can not predict what the state of affairs around XHTML 
will be in the next say, 5 years, when the specification gets 
implemented. It can specify a list of minimum required technologies that 
a browser has to support, and it is fine if XHTML is not part of that. 
However that should not preclude a standardised file extension/MIME type 
mapping.

Different subject;

About treating XHTML as text/html; I don’t know about that. The practice 
is fine by itself, I do that on my website and I would like to use it if 
I were to create a ‘widget’ (if necessary to support IE). But I do think 
it is better if such behaviour is a conscious decision by the author, so 
that he is fully aware that it is happening. As the zip file ‘replaces’ 
the web server, it would have to offer some kind of support for this.

Probably the best way to do this is to keep the internal mappings 
simple, but adding support for multiple types to the mappings file (that 
can override browser mappings):

.xhtml application/xhtml+xml;q=1.0,text/html;q=0.5

That would work :).

~Laurens

-- 
Note: New email address! Please update your address book.

~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~
Laurens Holst, student, Utrecht University, the Netherlands
Website: www.grauw.nl. Backbase employee; www.backbase.com