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

Re: ABNF or code fragments?

From: Yves Lafon <ylafon@w3.org>
Date: Tue, 23 Feb 2010 09:00:56 -0500 (EST)
To: Philip Jägenstedt <philipj@opera.com>
cc: Jack Jansen <Jack.Jansen@cwi.nl>, Media Fragment <public-media-fragment@w3.org>
Message-ID: <alpine.DEB.1.10.1002230853340.5071@wnl.j3.bet>
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.
(If you think that yes, how about 
http://www.example.com/foo%23%25252525252525252525252525252574=1 ?)

> If there is anything vague about the processing requirements, please point 
> out what is ambiguous so we can fix it.

Baroula que barouleras, au tiéu toujou t'entourneras.

Received on Tuesday, 23 February 2010 14:01:15 UTC

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