W3C home > Mailing lists > Public > www-tag@w3.org > December 2008

Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.

From: Dan Brickley <danbri@danbri.org>
Date: Mon, 01 Dec 2008 17:31:31 +0000
Message-ID: <49341F73.4080504@danbri.org>
To: "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>
Cc: Marcos Caceres <marcosscaceres@gmail.com>, "www-tag@w3.org" <www-tag@w3.org>, public-webapps <public-webapps@w3.org>

Williams, Stuart (HP Labs, Bristol) wrote:

>>> Well there are ways around that, add a package description
>>> or meta-data file either at the root of the package or at
>>> each directory level and have it carry media-type information
>>> - or use 'magic numbers' or (if you really must - in the
>>> absense of other authoritative information), sniff/guess
>>> though I think that should be the least preferred option.
>>>
>> Right. The new proposal is that we use file extension mappings to MIME
>> types, and if that fails, result to sniffing. We are reluctant to
>> introduce a meta-data format at this point.

(Just allow RDFa+XHTML and leave it to the marketplace...)

>> For version 2 of widgets,
>> it might be useful to either introduce the meta-data format or  have
>> an Apache-like file extensions to MIME type mapping. For example:
>>
>> image/gif .gif
>>
>> Note however, that widget engine in the wild have no problem working
>> without MIME info. From what I have seen, they all do just fine either
>> sniffing or using file extensions to derive the content types.
>>
>>> Anyway - that zip files don't intrinically maintain such
>>> info is not a show stopper - though I would have thought that
>>> carrying media-type information is a natural requirement for
>>> a packaging format for the web.
>>>
>> I'm not sure it is. When a MIME type is registered with IANA, the file
>> extension is also registered.
> 
> What is registered (RFC 4288 section 4.11) is a list of file name extensions commonly used with the media-type.
> It does *not* reserve the extension for exclusive use with that media-type.
> It does *not* prevent other arbitrary file name extension or indeed no-extension being used.
> 
> So... yes not a bad hint, but nothing is certain.
> 
>> So one has a standardized way to derive
>> the media type for a file by the file extension.
> 
> Not with certainty...

So this seems like a very small piece of metadata ('this filetree 
follows the IANA filename to media type mappings') has a lot of value. 
If the versions of the IANA mapping are easily identified, the metadata 
becomes a URI rather than a single bit. Either way, you can gain a lot 
from not a lot, I think.

cheers,

Dan

--
http://danbri.org/
Received on Monday, 1 December 2008 17:32:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:08 GMT