- 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