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

Re: Media Fragments URI parsing: pseudo algorithm code

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Mon, 5 Jul 2010 18:55:50 +1000
Message-ID: <AANLkTim52dBYbh0VWiqkRlvTjbm4hGxtBBuXwliZCbO7@mail.gmail.com>
To: RaphaŽl Troncy <raphael.troncy@eurecom.fr>
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>
On Sat, Jul 3, 2010 at 12:49 AM, RaphaŽl Troncy
<raphael.troncy@eurecom.fr> wrote:
> 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?

Only just to explicitly express the intent and to move the syntax into
the normative section.

As Philip said: "All dimensions so far are orthogonal. It would be
pretty bad language design to allow a new property to change the
semantics of an old one to the point that it is better that both are
ignored than only the old one being recognized."

I think we need to capture this.

Received on Monday, 5 July 2010 08:57:57 UTC

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