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

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
-- 
Marcos Caceres
http://datadriven.com.au

Received on Monday, 1 December 2008 17:40:07 UTC