Media fragment parsing

The User Agent Media Fragment Resolution and Processing section [1]  
requires conforming UAs to use a validating parser, which is not an option  
for a UA which wishes to be be forward-compatible. Example: a UA  
implements a strict validating parser for MF 1.0, capable of parsing the  
"t", "xywh", "track" and "id" dimensions using their respective syntaxes,  
rejecting anything else as invalid. Then MF 1.1 is released, introducing a  
"frame" syntax for time, e.g. "t=frame:25". Graceful degradation in a MF  
1.0 parser would not be possible, as such a parser is required to reject  
invalid syntax.

In my opinion the spec needs a parsing algorithm for the media fragment  
syntax that defines the exact order in which a fragment is processed and  
how to deal with unknown syntax, duplicate entries and so on. It doesn't  
have to be complicated, just something like:

1. split the string on '&'; let the result be namevalues
2. for each string namevalue in namevalues:
3. split namevalue on the first occurence of '=', let the result be two  
strings name and value
4. if either name or value is the empty string, fail
5. if name is "t", ...
6. if name is "xywh", ...
10. otherwise, name is not a valid dimension. (validators emit an error  
here, other parsers ignore it and continue)

The parsing of each dimension of course also needs to be specified. In  
most cases simply referring to the ABNF and simply ignoring non-conforming  
input should be OK.

I would suggest that for multiple occurrences of the same dimension, the  
last one is the one which takes effect. This is to allow graceful  
degradation in the transition between two syntaxes, e.g. "t=frame:25&t=1s"  
(framerate of the resource is 25 in this example).

Finally, I think that requiring a conforming user agent notify the user of  
invalid input is unwise. That is the job of a validator, sane user agent  
behavior is to proceed as best it can with the input it has.

I'd also like to point out that the ABNF for NPT does not match RFC2326.  
It allows there to be 0 or more digits following the decimal point, while  
the MF ABNF allows 1 or more digits. Simply importing npt-sec | npt-hhmmss  
would probably be best.


Philip Jägenstedt
Core Developer
Opera Software

Received on Tuesday, 24 November 2009 10:21:24 UTC