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

Re: Media fragment parsing

From: Yves Lafon <ylafon@w3.org>
Date: Tue, 24 Nov 2009 10:27:52 -0500 (EST)
To: Philip Jägenstedt <philipj@opera.com>
cc: Media Fragment <public-media-fragment@w3.org>
Message-ID: <alpine.DEB.1.10.0911240955240.25669@wnl.j3.bet>
On Tue, 24 Nov 2009, Philip Jägenstedt wrote:

> 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.

Yes, there is difference between grammar-validity and value-validity, and 
I think that "valid mediafragment" should be read as "a fragment that was 
parsed as something known by the application"

> 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)

That would mandate one implementation and possibly not the most optimal 
version of it.

> 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.


> [1] 
> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#naming-processing-ua

Baroula que barouleras, au tiéu toujou t'entourneras.

Received on Tuesday, 24 November 2009 15:27:55 UTC

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