Re: Feedback from FOMS

On Wed, 27 Jan 2010 13:26:26 +0100, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

> 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.

My main point is that right now there are no conformance requirements, so  
it's impossible to test if a browser "supports media fragments" at the  
HTTP level, which 5.2.1 is about. If no-one objects, I'd like to mark  
5.2.1 and 5.2.2 non-normative unless there are testable requirements.  
(Note though that I don't believe it's very meaningful to define the  
requirements in terms of HTTP, but rather think it should be in terms of  
playback behavior.)

>> 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?

First, as I mentioned, there is no syntax or processing requirements for  
new HTTP headers, neither for the client side or server side.

More importantly, there is still nothing that map media fragment  
dimensions (output of 5.1.3) into actual behavior. In my opinion section  
5.1.4 General Interpretation and 5.1.5 Error Handling should be merged  
into a single section detailing how to process a set of media fragment  
dimensions. Lots of Section 3 URI fragment and URI query could also be  
merged into this, especially 3.2 Resolving URI fragments within the user  
agent and 3.3 Resolving URI fragments with server help.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Wednesday, 27 January 2010 12:54:39 UTC