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

Processing requirements

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

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  

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 11:56:08 UTC

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