[uf-new] Separating File Content from File Format

Charles Iliya Krempeaux supercanadian at gmail.com
Fri Apr 6 14:07:34 PDT 2007


Hello Manu,

On 4/6/07, Manu Sporny <msporny at digitalbazaar.com> wrote:
> Charles Iliya Krempeaux wrote:
> > I don't think we are disagreeing.
> >
> > You are saying that it says we SHOULD NOT use them.  And I'm not arguing
> > that.
> >
> > But "SHOULD NOT" is NOT the same a "MUST NOT".
>
> Agreed. Although, I don't think I made myself clear in the last post to
> this thread. The following I see as a MUST NOT:
>
> "MIME implementations must ignore any parameters whose names they do not
> recognize."
>
> In other words, "Web browsers MUST NOT process parameters whose names
> they do not recognize". Parameter recognition is based on MIME-type,
> isn't it? Or am I missing something?

Again... we are not disagreeing here.  I am not arguing this.

This still does not stop people from serving resources (on the web)
using Content Type with non-registered Content Type parameters.


> > And therefore, despite the encouragement (from the spec) to NOT make
> > up your own Content Type parameters, you still could.  And if you did,
> > you would still be complying with the spec.
>
> Isn't this a slippery slope?

I think this was an intended path to extension.

Much like developers defining their own (HTML) class name, and
developers defining their own "x-" prefixed MIME types, and developers
defining their own XML namespaces.


> Remember, we're not just talking about one
> MIME-type here, we're talking about possibly adding 2-5 parameters for
> all of these MIME-types:
>
> audio/basic
> audio/mp4
> audio/mpeg
> audio/mpeg4-generic
> audio/ac3
> video/DV
> video/H264
> video/mp4
> video/mpeg
> video/quicktime
> video/vc1
> image/gif
> image/jpeg
> image/tiff
> image/png
>
> ---------------------------------------------------------------------
>
> Just to set up an alternative for discussion purposes. If we wanted to
> specify the following for a file (WARNING: Strawman ahead):
>
> type, audio-codec, audio-codec-sample-rate, video-codec-sample-rate,
> video-codec-bitrate, size-in-octets, URL
>
> We could then mark-up the following text in a uF:
>
> ----------------------------------------------------------------------
> We just went rock climbing at The Gorge in West Virginia. Here are two
> downloadable files of us doing Angels Arete:
>
>  The Gorge - DV   (54MB, PCM 48Khz audio, HD-VCR/1125-60 video)
>  The Gorge - MPEG (22MB, MP3 192Kbps audio, MPEG-2 video)
> ----------------------------------------------------------------------
>
> We could create a hFile uF like so:
>
> <div class="hFile">
>  <a type="video/DV" href="/angels_arete.dv">The Gorge - DV</a>
>   (<abbr class="size-in-octets" title="56623104">54MB</abbr>,
>    <span class="audio-codec">PCM</span>
>    <abbr class="audio-codec-sample-rate">48Khz</span> audio,
>    <span class="video-codec">HD-VCR/1125-60</span> video)
> </div>
>
> <div class="hFile">
>  <a type="video/mpeg" href="/angels_arete.mpg">The Gorge - MPEG</a>
>   (<abbr class="size-in-octets" title="23068672">22MB</abbr>,
>    <span class="audio-codec">PCM</span>
>    <abbr class="audio-codec-sample-rate">192Kbps</span> audio,
>    <span class="video-codec">MPEG-2</span> video)
> </div>
> ----------------------------------------------------------------------
>
> The argument for the first alternative, adding parameters to
> pre-existing MIME-Types, seems a bit shaky. The second alternative,
> adding classes, is based on a widely accepted standard.
>
> Which one is the better solution for describing file formats?

Well... 2nd choice... with the (HTML) class names... is definitely
more in tune with the Microformat way.



See ya

-- 
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/


More information about the microformats-new mailing list