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

On Tue, Jun 22, 2010 at 3:57 PM, Davy Van Deursen
<davy.vandeursen@ugent.be> wrote:
> Hi Silvia,
>
>> -----Original Message-----
>> From: public-media-fragment-request@w3.org [mailto:public-media-
>> fragment-request@w3.org] On Behalf Of Silvia Pfeiffer
>> Sent: dinsdag 22 juni 2010 6:18
>> To: Jack Jansen
>> Cc: raphael.troncy@eurecom.fr; Media Fragments Working Group WG
>> Subject: Re: ACTION-178: Review the complete document, remove
>> unnecessary editorial notes before publication (Media Fragments Working
>> Group)
>>
>> On Tue, Jun 22, 2010 at 9:01 AM, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com>
>> wrote:
>> > On Tue, Jun 22, 2010 at 8:07 AM, Jack Jansen <Jack.Jansen@cwi.nl> wrote:
>> >>
>> >> On 21 jun 2010, at 15:49, Silvia Pfeiffer wrote:
>> >>
>> >>> 5. Clarify "track" dimension
>> >>> I am rather confused right now: how did we decide to do multiple
>> >>> tracks? In some places we talk about several tracks being able to be
>> >>> defined, but only a single track per spec (see 4.3.3 and the
>> >>> examples), and in other places we talk about there only being one
>> >>> track dimension allowed (D.2 3c and 5.1.2, 5.1.2.1). Can somebody
>> >>> clarify?
>> >>
>> >> We decided on multiple tracks recently (I actually seem to remember
> that
>> you suggested it,  because your contacts said that single-track-selection
>> would be useless). But, indeed, most of the text was written when we still
>> thought of single track selection only.
>> >
>> > Yes, multiple tracks. But how? Through multiple track parameters or
>> > through one with semicolon-separated elements? I cannot remember
>> > whether we made an actual decision on that. Once somebody clarifies
>> > this for me, I can fix it either way. I would personally prefer them
>> > all in one track parameter, since that will make the different
>> > dimensions more consistent.
>>
>> I think this example from Ninsuna suggests also that we will put multiple
>> tracks in one track param:
>> http://ninsuna.elis.ugent.be/DownloadServlet/mfwg/fragf2f.ogv?track=ogg
>> _1;ogg_2
>
> 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.

I do not remember why we even discussed having multiple "track"
parameters instead of putting all the track names in one "track"
param.

Cheers,
Silvia.

Received on Tuesday, 22 June 2010 06:04:58 UTC