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

Re: Segment production rule

From: Philip Jägenstedt <philipj@opera.com>
Date: Tue, 09 Mar 2010 20:01:32 +0800
To: Raphaël Troncy <raphael.troncy@eurecom.fr>
Cc: "Media Fragment" <public-media-fragment@w3.org>
Message-ID: <op.u9aucubxatwj1d@philip-pc.oslo.opera.com>
On Tue, 09 Mar 2010 18:53:18 +0800, Raphaël Troncy  
<raphael.troncy@eurecom.fr> wrote:

> Philip (cc-ing the whole group)
>
>>> Philip,
>>>
>>> In revision 1.72, you remove the *segment productions. Why?
>>> Segment is the hat over fragment and query ... since we expect
>>> ultimately to cover both and re-use some bits of syntax.
>>> Why did you remove it?
>>
>> For the reasons stated in the email I sent:
>>
>> On Tue, 09 Mar 2010 16:18:03 +0800, Philip Jägenstedt
>> <philipj@opera.com> wrote:
>>
>>> E.g. the timeprefix and timeparam syntaxes should be matched against
>>> these
>>> strings, *not* any part of the URI. The timesegment syntax is simply
>>> removed as it (and all other foosegment productions) violates the
>>> layering
>>> of media fragments on top of name-value lists.
>>
>> The *segment productions simply make no sense if we layer media
>> fragments on top of name-value lists, unless we have a way to express
>> "any string that after percent-decoding and UTF-8-decoding is ...".
>
> There is no violation. Wait that Yves introduces (again!) this  
> production rule and you will see that there is no contradiction.
> You miss the fact that we wanted a generic syntax that works for query  
> and fragments.

If MF is to be modeled on top of a name-value lists, then clearly it is a  
violation of layers for the MF syntax to be concerned with the separators  
used in the layer below.

This *is* a generic syntax that works for both query component and  
fragments, since the definition of fragment and query in the URI spec is  
exactly the same.

-- 
Philip Jägenstedt
Core Developer
Opera Software
Received on Tuesday, 9 March 2010 12:02:21 GMT

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