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

Re: Media Fragments URI parsing: pseudo algorithm code

From: Philip Jägenstedt <philipj@opera.com>
Date: Wed, 07 Jul 2010 17:22:52 +0200
To: "Yves Lafon" <ylafon@w3.org>, Raphaël Troncy <raphael.troncy@cwi.nl>, raphael.troncy@eurecom.fr
Cc: "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>, "Bjoern Hoehrmann" <derhoermi@gmx.net>, public-media-fragment@w3.org
Message-ID: <op.vfhboewratwj1d@philip-pc.gothenburg.osa>
On Wed, 07 Jul 2010 16:27:19 +0200, Raphaël Troncy <raphael.troncy@cwi.nl>  
wrote:

>> You can only know it's a media resource when you dereference it.
>> http://www.example.com/map#lat=-16.5&long=-151.7 is a valid Media
>> Fragment,
>
> NOT according to you. It is a valid URI fragment.
>
>>> So, I actually disagree with the notion that this is no a valid MF URI
>>> - it is a valid MF URI - it is just not a valid MF dimension.
>>
>> Needless to say that I disagree ;)
>
> I'm all for continuing the discussion, at least all the summer and then  
> I wonder how should we move forward: Would a vote be useful?

That depends on what the vote is on. The core question might be phrased as  
"When encountering a name-value pair that is not specified by MF 1.0, what  
should implementations do?" The two options on the table are (1) ignore  
the entire fragment, as if it were not present at all or (2) ignore only  
that name-value pair and continue processing the others.

I would prefer if the decision was on such a principal level, and that the  
editor(s) then implement the decision by changing the syntax and  
processing sections to be consistent.

Alternatively, the vote could be between two competing changes to make the  
spec consistent, but that inevitably means that someone has to do a lot of  
spec editing that gets voted down and is wasted.

-- 
Philip Jägenstedt
Core Developer
Opera Software
Received on Wednesday, 7 July 2010 15:23:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:39 GMT