- From: Philip Jägenstedt <philipj@opera.com>
- Date: Wed, 02 Dec 2009 12:55:24 +0100
- To: "Media Fragment" <public-media-fragment@w3.org>
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) 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 11:56:08 UTC