Hello Manu,
On 4/6/07, Manu Sporny <[EMAIL PROTECTED]> 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/
_______________________________________________
microformats-new mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-new
