Re: ABNF or code fragments?

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).

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

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Tuesday, 23 February 2010 09:57:13 UTC