Re: Feedback from FOMS

On Wed, Jan 27, 2010 at 11:54 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> 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.)

I find the topic of non-normative vs normative a bit hard to grasp.
How does the URI spec become normative or non-normative?


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

Not in section 5.2.1.

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

Section 3 is giving a general overview of how it is all expected to
work and section 5.2 provides the concrete HTTP exchanges for this. We
could merge them but does it make it more readable? Section 3 sets the
scene for everything else, including the syntax of section 4. I
believe the structure is logical, even though there is a bit of
repetition between 3 and 5.2.

But indeed, there are several sections that are not finished, in
particular the error handling ones. It may be possible that 5.1.4 and
5.1.5 make sense to be merged. I don't know - we don't have enough
error handling in them yet.

Cheers,
Silvia.

Received on Wednesday, 27 January 2010 22:39:31 UTC