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

Re: Media Fragments URI parsing: pseudo algorithm code

From: Yves Lafon <ylafon@w3.org>
Date: Wed, 30 Jun 2010 10:22:15 -0400 (EDT)
To: Philip Jägenstedt <philipj@opera.com>
cc: Jack Jansen <Jack.Jansen@cwi.nl>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Raphaël Troncy <raphael.troncy@eurecom.fr>, Media Fragment <public-media-fragment@w3.org>
Message-ID: <alpine.DEB.1.10.1006301018440.9673@wnl.j3.bet>
On Wed, 30 Jun 2010, Philip Jägenstedt wrote:

> You cannot write a robust MF parser based on this grammar, because 
> t=1&foo=bar is not a valid production, meaning that any future extension foo 
> of MF will cause that parser to fail completely. Either the grammar itself 
> must be relaxed, or the parsing must be defined normatively and handle some 
> things which are not valid productions of the grammar.

What do you mean by "robust" ?

>> With the current grammar, it is allowed only in track and id productions.
>> So it is perfectly compatible with the processing defined in rfc3986 and 
>> perfectly allows #track=A%20%26%20B&t=10
> No disagreement that we need to define it, thankfully. The disagreement is 
> only where to decode percent-encoding.

RFC3986 gives the answer, after the URI components are parsed (and we 
define here how to split out in components).

> <issue>
> MF parsing must be defined normatively in the MF spec itself, meeting these 
> conditions:
> 1. should handle all valid productions of the ABNF syntax correctly and, 
> where necessary, input which is not valid per the syntax.
> 2. must be forward-compatible, so that future extensions to MF do not break 
> existing MF parsers. (Compare to how new HTML elements and attributes or CSS 
> properties degrade in implementations that don't understand them.)

I completely disagree with this, as it may preclude other uses than 
mediafragment to use an "a=b" syntax.

> 3. should match as closely as possible how query components on the form 
> a=1&b=2 are parsed by existing server-side software (e.g. ASP, PHP, JSP, Perl 
> CGI)
> </issue>
> An implementation that conforms exactly to the (current, non-normative) ABNF 
> fails condition 2 (e.g. t=1&foo=bar) and is not an option.

As I completely disagree with 2, strict ABNF makes perfect sense.

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

Received on Wednesday, 30 June 2010 14:22:24 UTC

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