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

Re: Feedback from FOMS

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 27 Jan 2010 23:26:26 +1100
Message-ID: <2c0e02831001270426h71d82e82s9d429672f714aa33@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: Media Fragment <public-media-fragment@w3.org>
On Wed, Jan 27, 2010 at 10:54 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Wed, 27 Jan 2010 12:25:55 +0100, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>> On Wed, Jan 27, 2010 at 10:17 PM, Philip Jägenstedt <philipj@opera.com>
>> wrote:
>>> On Wed, 27 Jan 2010 11:59:59 +0100, Silvia Pfeiffer
>>> <silviapfeiffer1@gmail.com> wrote:
>>>> On Wed, Jan 27, 2010 at 9:46 PM, Silvia Pfeiffer
>>>> <silviapfeiffer1@gmail.com> wrote:
>>>>> On Wed, Jan 27, 2010 at 9:41 PM, Philip Jägenstedt <philipj@opera.com>
>>>>> wrote:
>>>>>> On Wed, 27 Jan 2010 10:21:34 +0100, Raphaël Troncy
>>>>>> <raphael.troncy@cwi.nl>
>>>>>> wrote:
>>>>>>> Hi Silvia,
>>>>>>> Thanks for this very valuable report from FOMS.
>>>>>>>> After it was understood what the spec is about, it was suggested we
>>>>>>>> split out those sections that are already stable and move those that
>>>>>>>> are still in the works into a draft for later release. Thus, we can
>>>>>>>> create a first, simple "versions" that can be implemented in full
>>>>>>>> right now.
>>>>>>> I understand the need for the developers to be informed of what is
>>>>>>> stable
>>>>>>> in a evolving spec and what is not, but I'm not a big fan of
>>>>>>> splitting
>>>>>>> documents. Our charter tells what the 1.0 version should cover. I
>>>>>>> would
>>>>>>> rather suggest we mark explicitly in our document the sections that
>>>>>>> we
>>>>>>> consider are stable giving a clear 'go' to web developers to start
>>>>>>> implement
>>>>>>> them and mark as unstable the sections we are actively working on.
>>>>>> I think this is a good idea, it's approximately how HTML5 handles the
>>>>>> issue
>>>>>> of sections with different maturity levels in the same spec.
>>>>> I'm happy with this, too.
>>>> In the meeting today I suggested that in the next meeting we get the
>>>> section that I think we all agree on (section 5.2.1
>>>> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-protocol-UA-mapped
>>>> and everything that it includes) into a shape such that we can mark it
>>>> as "finished and read for implementation". Then we can hand this on to
>>>> browser developers (in particular Opera and Firefox) for
>>>> implementation.
>>>> Philip mentioned one outstanding issue, which has to do with time spec
>>>> and he will raise it on mailing list so we can resolve it by next
>>>> week.
>>>> Further then: prepare your arguments for next week's meeting if you
>>>> don't think 5.2.1 is ready. :-)
>>> I don't think this section is ready, but encouraging experimental
>>> implementations and soliciting feedback is one of the best ways to make
>>> it
>>> better. As far as I can see the syntax for the new HTTP headers isn't
>>> defined anywhere.
>> 5.2.1 has no new HTTP headers - it simply relies on the browser using
>> byte range requests. Its the next sections that have these and yes, I
>> agree, these aren't ready yet.
> Ah, you're right. As far as I can see the section it adds no conformance
> requirements and mostly has to do with HTTP semantics. Is there anything in
> this which could be made into conformance requirements for which it is
> possible to write tests and see that implementation passes or fails? Perhaps
> something as simple as requiring that user agents use byte range requests
> would do, as that would fail implementations which just GET the whole
> resource.

Yes, we can definitely do a byte range request support test somehow.
It's just the support of the URI spec in the browser though that we
are after in this section.

> 5.2.2 Server mapped byte ranges is also a big example.

I'm not sure 5.2.2 is non-controversial, but let's find out in the next meeting.

> For both sections, I think we should identify the normative parts (if any),
> put them at the top and clearly mark the rest as an informative example.

Yup, good idea. Normative part simply is the syntax support for 5.2.1, really.

> P.S. It's a bit concerning to me that the ratio between non-normative and
> normative content in the spec is so high, but at the same time I hesitate to
> suggest removing anything (!) because I know people have worked hard on it.
> Identifying and factoring out the conformance requirements from the big
> discussion sections would go some way to improving the ratio :)

Which conformance requirements?

Received on Wednesday, 27 January 2010 12:27:20 UTC

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