Re: Feedback from FOMS

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?

Cheers,
Silvia.

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