- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Wed, 27 Jan 2010 23:26:26 +1100
- 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? Cheers, Silvia.
Received on Wednesday, 27 January 2010 12:27:20 UTC