Re: Feedback from FOMS

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.

5.2.2 Server mapped byte ranges is also a big example.

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.

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 :)

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Wednesday, 27 January 2010 11:55:20 UTC