Re: ACTION-187: extensibility and parsing

Dear Philip,

> As request, a short summary of the long standing issue of syntax,
> parsing and how that relates to extensibility.

Thanks for having start up this thread. We have closed today the 
action-187 (and 186) as you may have seen in the minutes. We have also 
resolved that we should do the option 2 you described below (consensus 
from all minus one neutral among the people who have expressed an opinion).

We have further precise how the specification will manage extensibility:

1/ A media fragment URI is indeed a set of key/value pairs for which at 
least one key is recognized by our grammar
2/ The ABNF grammar that describes the media fragment syntax will be 
edited (see ACTION-189) so that:
   . The production rule of 'mediasegment' is now:
mediasegment = namesegment / axissegment / extensionsegment
extensionsegment = extensionprefix '=' extensionparam
   . Additional prose states that 'extensionsegment' cannot redefine one 
of the current axis, so e.g., extensionprefix cannot be 't' or 'track' 
or 'id' or 'xywh'
3/ We could add an additional paragraph stating how the parsing of the 
media fragment URI should be done

> How will implementations of MF 1.0 handle t=10,500&freq=300,3000 ? This
> is the core point of disagreement, and the question is really about how
> MF 1.0 parsers should work. Leaving it undefined is not a good option,
> as the history clearly shows.

Indeed. With the current decision:
  . <uri>#t=10,500&freq=300,3000 will be a valid MF 1.0 URI
  . <uri>#freq=300,3000 will *NOT* be a valid MF 1.0 URI

> 1. Require that parsing follow a strict ABNF syntax like the one we
> have. Since freq is not part of the MF 1.0 syntax, parsing
> t=10,500&freq=300,3000 will fail and the whole fragment will be ignored,
> including t=10,500.
>
> 2. Require that parsing follow an algorithm or a more forgiving ABNF
> syntax. The concrete suggestion I've made is that the algorithm or
> syntax should match how query strings work. That is, a list or key-value
> pairs is formed by splitting the string on & and =. As a second step,
> that list is traversed to match the keys against the dimensions and
> parsed according to the ABNF syntax of each dimension. Crucially,
> unrecognized/invalid keys or values are ignored. That means that in the
> above example, the time dimension will keep working even if an
> unrecognized (to a MF 1.0 implementation) freq dimension is used.

Please comment on this decision stating either that you agree or you 
disagree so that I can implement the ACTION-189.
Thanks.
Best regards.

   Raphaël

-- 
Raphaël Troncy
EURECOM, Multimedia Communications Department
2229, route des Crêtes, 06560 Sophia Antipolis, France.
e-mail: raphael.troncy@eurecom.fr & raphael.troncy@gmail.com
Tel: +33 (0)4 - 9300 8242
Fax: +33 (0)4 - 9000 8200
Web: http://www.eurecom.fr/~troncy/

Received on Wednesday, 29 September 2010 14:07:53 UTC