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: Marcos Caceres <marcosscaceres@gmail.com>
Date: Mon, 1 Dec 2008 17:39:25 +0000
Message-ID: <b21a10670812010939g390ec7b9n4e9fc1adfd95ee6d@mail.gmail.com>
To: "Dan Brickley" <danbri@danbri.org>
Cc: "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>, "www-tag@w3.org" <www-tag@w3.org>, public-webapps <public-webapps@w3.org>

On Mon, Dec 1, 2008 at 5:31 PM, Dan Brickley <danbri@danbri.org> wrote:
> 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...)

right :)

>>> 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.

So we are clear, what do you have in mind here?

Kind regards,
Marcos Caceres
Received on Monday, 1 December 2008 17:40:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:25 UTC