Re: Processing requirements

On Wed, 2 Dec 2009, Philip Jägenstedt wrote:

> Following up on my previous email and todays IRC-conference (for me).
>
> I won't get involved in the editors stylistic choices between ABNF, 
> equivalent parsing algorithms (only the side effects of which are normative) 
> or any other spec technique, but would request that at least the following 
> are defined:
>
> 1. Splitting of name-value pairs
>
> The current ABNF only allows joining timesegment / spacesegment / 
> tracksegment by "&", which means that e.g. #t=5& is not allowed because it 
> has a trailing &, which is very easy to get by accident if you write a script 
> like this:
>
> urifrag = '#':
> for d in dimensions:
>   urifrag += d + '&'

well, you can always do something like

   urifrag = ''
   for d in dimensions:
      urifrag += (urifrag=''?'#':'&') + d;

But that's orthogonal to your issue about semi-valid syntax.

> This specific case *can* be fixed in the ABNF, but leads into the next issue:
>
> 2. Handling of unrecognized syntax
>
> This means that #u=12&t=5 can still proceed to getting the time offset 5. Not 
> allowing this makes it impossible to extend MF in the future as any new 
> syntax is invalid per the current spec.
>
> As a necessary (but unsightly) side-effect, anything between & that isn't 
> recognized should be ignored, including the empty string. Thus a conforming 
> UA should be able to handle this extreme:
>
> #&&=&=tom&jerry=&t=34&t=meow:0# (time offset 34 seconds)
>
> 3. Processing order
>
> As an example, what is the result of processing #t=5&t=10 ? I think the 
> result should be 10, because it is what you would usually implement by 
> mistake if not making a conscious choice.
>
> The other option is that duplicating any dimension should cause the entire 
> fragment to be ignored, which I do not support.
>
> I trust none of this should be controversial. By having well-defined 
> processing we can avoid some of the reverse-engineering and 
> defacto-but-not-not-speced behavior that inevitably happens otherwise. After 
> these parts have been written, I will be happy to review the spec again.
>
> It will also be important to have a comprehensive test suite that makes sure 
> that an implementation isn't *more* forgiving than what the spec allows, but 
> that is in the future.
>
>

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

         ~~Yves

Received on Wednesday, 2 December 2009 14:50:47 UTC