W3C home > Mailing lists > Public > public-media-fragment@w3.org > July 2010

Re: Media Fragments URI parsing: pseudo algorithm code

From: RaphaŽl Troncy <raphael.troncy@eurecom.fr>
Date: Fri, 02 Jul 2010 16:49:02 +0200
Message-ID: <4C2DFC5E.7000202@eurecom.fr>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
CC: Yves Lafon <ylafon@w3.org>, Philip Jšgenstedt <philipj@opera.com>, Jack Jansen <Jack.Jansen@cwi.nl>, Media Fragment <public-media-fragment@w3.org>
Hi Silvia,

> If that is the case, our spec is inconsistent. We have a section that states:
> "Note that a general URI fragment or query string specified on a media
> resource may contain several field-value pairs. They are not
> restricted to the ones specified here, since applications may want to
> use additional other parameters to communicate further requests to
> custom servers."

And I remember that this is clearly what the group wants.

> I was always under the impression that we had agreed that additional
> name-value pairs are allowed and don't make the ones that we define
> invalid. I was also under the impression that our ABNF allowed for
> this.

Indeed, and I step back since I overlook the ABNF syntax.
   - a mediasegment can ONLY be namesegment OR a axissegment (time, 
space, track)
   - BUT a segment can be a mediasegment OR a set of pchar
I used to only look at the production rule of the mediasegment, thus my 
wrong interpretation. Therefore, our syntax clearly allows to have new 
name-value pairs.
The fact that this bit of syntax is only specified in a non-normative 
appendix is still a problem. It should also be in the section 4.3.5.

I don't see anymore what are the remaining problems posed by Philip and 
Yves. Please, could you please both clarify?


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 Friday, 2 July 2010 14:51:05 UTC

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