Re: Processing requirements

On Wed, 02 Dec 2009 12:55:24 +0100, Philip Jägenstedt <philipj@opera.com>  
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 + '&'
>
> 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)

If it isn't clear, in 1 I'm actually talking about splitting the list of  
name-value pairs, not the name-value pairs themselves. In 2, I'm not  
suggesting anything strange, just splitting by "&" to get "t=34" and a lot  
of garbage that is discarded.

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


-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Wednesday, 2 December 2009 15:42:00 UTC