W3C home > Mailing lists > Public > public-media-fragment@w3.org > December 2009

Re: Processing requirements

From: Philip Jägenstedt <philipj@opera.com>
Date: Wed, 02 Dec 2009 16:41:16 +0100
To: Philip Jägenstedt <philipj@opera.com>, "Media Fragment" <public-media-fragment@w3.org>
Message-ID: <op.u4bhu21gatwj1d@sisko.linkoping.osa>
On Wed, 02 Dec 2009 12:55:24 +0100, Philip Jägenstedt <philipj@opera.com>  

> 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

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