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

Re: ABNF or code fragments?

From: Philip Jägenstedt <philipj@opera.com>
Date: Tue, 23 Feb 2010 22:30:41 +0800
To: "Yves Lafon" <ylafon@w3.org>
Cc: "Jack Jansen" <Jack.Jansen@cwi.nl>, "Media Fragment" <public-media-fragment@w3.org>
Message-ID: <op.u8k3xfd4atwj1d@philip-pc.oslo.opera.com>
On Tue, 23 Feb 2010 22:00:56 +0800, Yves Lafon <ylafon@w3.org> wrote:

> On Tue, 23 Feb 2010, Philip Jägenstedt wrote:
>> On Tue, 23 Feb 2010 17:47:13 +0800, Jack Jansen <Jack.Jansen@cwi.nl>  
>> wrote:
>>> Off on a tangent, in this discussion.
>>>  On 23 feb 2010, at 01:46, Philip Jägenstedt wrote:
>>>> On Tue, 23 Feb 2010 04:36:03 +0800, Jack Jansen <Jack.Jansen@cwi.nl>  
>>>> wrote:
>>>>>  On 22 feb 2010, at 05:10, Philip Jägenstedt wrote:
>>>>>> There are two changes I would like to make, previously mentioned  
>>>>>> deep in some thread:
>>>>>>  1. Drop the trailing s from the npt syntax, which seems not to  
>>>>>> serve any real purpose as it only adds (a little) complexity but  
>>>>>> doesn't help disambiguate from any other form. It also isn't what  
>>>>>> is used in RTSP, if we want to align.
>>>>>>  2. Drop the 'quotes' around strings, which are completely  
>>>>>> unnecessary when spaces have to be percent-encoded anyway. Simply  
>>>>>> following the rules for splitting name-value pairs yields a string  
>>>>>> with any special characters decoded.
>>>>>   Would this work if I had, say, an ampersand (or any other special  
>>>>> character) in my track name?
>>>>>  I think it may work: IIRC the quotes were added before we  
>>>>> referenced rfc3986 for the string parameters, and I think the  
>>>>> "unreserved" character set is restricted enough.
>>>>>  But: someone with a strong ABNF background needs to check. We want  
>>>>> to make sure that "http://www.example.com/id=my%26name&t=5" actually  
>>>>> splits on & before turning the %26 into an ampersand.
>>>>  The splitting is defined our own spec, in  
>>>> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-name-value-components
>>>   That code seems to do what is needed.
>>>  But now I have a more serious question: it seems that the current  
>>> draft has gotten all ABNF removed, and replaced by code fragments??!?
>>>  I don't remember that such a change has come up during a teleconf.  
>>> Moreover, it is something that I have serious misgivings about: in a  
>>> standards document we should use formal declarative languages such as  
>>> ABNF as much as possible, and not vague english-based procedural  
>>> pseudo-code...
>> The syntax is defined by ABNF and is still there, just split across  
>> sections and using the W3C XML spec contructs instead of a big blob.
>> Processing however, can't be defined in terms of ABNF as it includes  
>> things like percent decoding, UTF-8 decoding and ignoring name-value  
>> pairs that aren't valid syntax (necessary to not break existing parsers  
>> by introducing new names in future versions of the spec).
> No, percent encoding is independent from the parsing using ABNF syntax.  
> But clearly one thing ABNF can't do is to put constraints that are not  
> in syntax-land. (Like checking that in t=t1-t2, t1 < t2).
> Also regarding percent escaping, people have the right to shoot  
> themselves in the foot if they want, but  
> http://www.example.com/foo#%74=1 is just _not_ a media fragment URI.

It's not *valid* (IIRC, "unnecessary" percent escaping is invalid per the  
URI spec) but the current processing rules will handle this case as  
percent decoding and UTF-8 decoding is performed on both name and value.  
This was done in order to be compatible with how deployed servers handle  
percent encoding in the query component. I see no practical reason to  
change this as one must implement the decoding for the value part anyway.

> (If you think that yes, how about  
> http://www.example.com/foo%23%25252525252525252525252525252574=1 ?)

There's no fragment component in that URI, so it doesn't contain a media  

Philip Jägenstedt
Core Developer
Opera Software
Received on Tuesday, 23 February 2010 14:31:23 UTC

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