Re: Media Fragments URI parsing: pseudo algorithm code

On Wed, 16 Jun 2010 14:42:03 +0200, Raphaël Troncy  
<raphael.troncy@eurecom.fr> wrote:

> Dear Philip,
>
> We have discussed today during the face to face meeting of the WG the  
> content of the section 4.1.1 and 4.1.2 that you wrote, regarding a  
> pseudo code algorithm example of how to process media fragments URI, see  
> also http://www.w3.org/2010/06/16-mediafrag-minutes.html#item07 though  
> very little has been scribed.
>
> We have decided to move this 2 subsections in a new Annex D - Notes on  
> parsing Media Fragments URI.
>
> The rationale is that this piece of text is informative, the ABNF syntax  
> being normative. The WG believe that the ABNF is self-contained for  
> implementers to use the right grammar tools to perform optimally the URI  
> syntax.
> Please let us know if you disagree with this decision.
>
>    Erik & Raphaël
>

Hi all,

I've been on vacation getting married, so sorry for my tardy reply.

This is the version I'm looking at:  
http://www.w3.org/TR/2010/WD-media-frags-20100624/

There's syntax and processing on two levels here.

1. name-value pairs delimited by "&" and "=".

2. syntax of the names and values of the four different dimensions, e.g.  
timeprefix and timeparam for the time dimension.

I do disagree with the change, because it leaves the spec without any  
normative requirements for how to parse level 1. The only thing we have is  
the non-normative segment/mediasegment and related productions in  
<http://www.w3.org/TR/2010/WD-media-frags-20100624/#collected-syntax-uri>.  
Apart from being non-normative, it is also incorrect as it doesn't capture  
the fact that any names and values of name-value pairs can be %-encoded,  
e.g. as in "%74=%6ept%3A%310". That definition doesn't appear anywhere in  
the normative text and should be removed.

If I am missing it, please point out which ABNF normatively defines the  
syntax for level 1: name-value pairs delimited by "&" and "=".

As for level 2, we have all the ABNF syntax productions, but nothing that  
binds them together, as D.2 Processing name-value lists does (did). I  
would be happy to see that replaced by a more strict definition achieving  
the same thing, or failing that, making D.2 normative again.

I will continue to bring up the issue of well-defined processing until it  
is resolved. MF is a small spec and it's not difficult to define achieve  
interoperability. That means that it should be possible for two different  
implementors to read the spec and implement two different parsers that  
have the exact same result for all possible input, valid or not. Without  
that, the spec shouldn't progress to Last Call. As usual, I don't care  
much what spec writing style is used to achieve this, as long as it is  
achieved.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Monday, 28 June 2010 14:24:01 UTC