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

Re: ACTION-178: Review the complete document, remove unnecessary editorial notes before publication (Media Fragments Working Group)

From: Jack Jansen <Jack.Jansen@cwi.nl>
Date: Tue, 22 Jun 2010 21:38:57 +0200
Cc: Davy Van Deursen <davy.vandeursen@ugent.be>, raphael.troncy@eurecom.fr, Media Fragments Working Group WG <public-media-fragment@w3.org>
Message-Id: <2CF5186A-B580-4E45-A7CB-96739D621A25@cwi.nl>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>

On 22 jun 2010, at 08:04, Silvia Pfeiffer wrote:
>> Currently, we indeed represent multiple tracks through one track param, both
>> at server-side through query parameters and at client-side (i.e, the Media
>> Fragments Player) through URI fragments. Note that representing multiple
>> tracks through multiple track params introduces difficulties when we use
>> query parameters, since the server will only interpret the first occurrence
>> of a track param ... So I would vote for combining multiple tracks into one
>> track param.
> Yes, I prefer that, too. It's also how it is in the HTTP headers and
> makes things more compact and easier to parse.

Now I am confused.

My personal preference is also for multiple track names specified in a single track= parameter (and similar for during http protocol handling), but what I remember is that this was considered to be impossible (or difficult?), because of the lack of a decent grammatical construct for the separator. This was the whole discussion about when percent-escaping is done.

As far as I remember things, this is why we opted for multiple track= parameters (even though this has the disadvantage of treating the track= parameter differently than the spatial and temporal parameters.

Does anyone remember why we ended up with multiple track= parameters?
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman
Received on Tuesday, 22 June 2010 19:39:38 UTC

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