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: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 23 Jun 2010 20:18:14 +1000
Message-ID: <AANLkTil86vNWLnQyYxiXPs50X3E8BYvTUoyfCu9fDViP@mail.gmail.com>
To: RaphaŽl Troncy <raphael.troncy@eurecom.fr>
Cc: Jack Jansen <Jack.Jansen@cwi.nl>, Media Fragments Working Group WG <public-media-fragment@w3.org>
2010/6/23 Silvia Pfeiffer <silviapfeiffer1@gmail.com>:
> 2010/6/23 RaphaŽl Troncy <raphael.troncy@eurecom.fr>:
>> Hi all,
>> Specific message on multiple tracks. I must play the memory of the group
>> since we have discussed this already and people don't look at the
>> resolution page :-)
>>> 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.
>> See
>> http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions#Media_Fragment_URI_Syntax
>> I quote:
>> "The WG resolved on 2010/03/09 †that the media fragment URI will allow
>> multiple values for the track dimension, using multiple occurrence of the
>> keyword 'track' (e.g.: #track=audio&track=video). (Note that this explicitly
>> contradicts a resolution we had on 2010/03/08 †that is now deprecated)."
>> Evidence of the decision, see:
>> http://www.w3.org/2010/03/09-mediafrag-minutes.html#item01 We say that we
>> will use multiple occurrences of the word 'track'.
> Yes, I just re-read that, too, after you pointed it out. I don't like
> it, but ok. Then we have to make sure we change it and we discuss what
> to do in the HTTP headers etc.
> I suggest only allowing multiple track params in the URI and
> converting them to a combined value in the HTTP header. This is the
> way it is mostly written right now (not completely though), but it
> needs to be made more explicit and explained that the UA has to change
> it over.

I've made those clarifications as discussed in today's phone call.

Received on Wednesday, 23 June 2010 10:19:07 UTC

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