W3C home > Mailing lists > Public > public-media-fragment@w3.org > January 2010

Re: Processing requirements

From: Philip Jägenstedt <philipj@opera.com>
Date: Sun, 17 Jan 2010 18:40:45 +0100
To: "Jack Jansen" <Jack.Jansen@cwi.nl>, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
Cc: "Media Fragment" <public-media-fragment@w3.org>
Message-ID: <op.u6ot17yosr6mfa@worf>
On Mon, 11 Jan 2010 12:10:31 +0100, Jack Jansen <Jack.Jansen@cwi.nl> wrote:

> On 11 jan 2010, at 11:31, Silvia Pfeiffer wrote:
>>>> If we think there's a real danger of name collisions we could go the  
>>>> whole
>>>> way and prefix our names with mf- or something, but then you get ugly
>>>> http://example.com/video.ogg?mf-t=3 urls. My preference is that for  
>>>> the 1.0
>>>> spec we just cross our fingers, and it if turns out we are wrong we  
>>>> fix
>>>> things with non-colliding names in the next version of the spec.
>>> The prefix idea is a good one, but how about forcing the extensions to  
>>> use
>>> it instead of MF, just like with CSS: -foo-name. This would be  
>>> applicable to
>>> the fragment syntax too if UAs want to experiment, so you might see  
>>> e.g.
>>> #t=20&-o-aspect=4:3 or something if Opera wants to be able to force the
>>> aspect ratio like this (we don't, it's just an example).
>> Interesting... we should discuss this idea of including a
>> "namespace"-style prefix. It makes it a bit lengthy and talkative, but
>> indeed easier to segment out from other name-value pairs.
> My suggestion is we keep this simple. At most: one non-normative  
> paragraph somewhere, where we state "If you want to extend the  
> name/value pairs please do so in a way that will likely not collide with  
> other people's names (including future versions of this spec). We  
> suggest use use something like -org-name, where org is an abbreviation  
> of your organization."

I decided to do nothing in my edits, I just added a note that we need to  
decide on this.

Philip Jägenstedt
Core Developer
Opera Software
Received on Sunday, 17 January 2010 17:41:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:43 UTC