Re: Media fragment parsing

Hi Philip,

I totally agree. Just as a careful note: section 5 is still in utter
turmoil - only up until section 4 is the spec fairly stable.

We're hoping to have that fixed soon! Then we would really love to get
your detailed feedback and input again!

I think what you are proposing can go into that section almost as
written (with a bit more detail). Other name-value pairs need to be
able to be defined by applications anyway - there's no need to be
restrictive.

Cheers,
Silvia.

On Tue, Nov 24, 2009 at 9:20 PM, Philip Jägenstedt <philipj@opera.com> 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.
>
> 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.
>
> [1]
> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#naming-processing-ua
>
> --
> Philip Jägenstedt
> Core Developer
> Opera Software
>
>

Received on Tuesday, 24 November 2009 10:25:58 UTC