Re: Feedback from FOMS

On Fri, 29 Jan 2010 00:02:41 +0100, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

> On Fri, Jan 29, 2010 at 9:53 AM, Philip Jägenstedt <philipj@opera.com>  
> wrote:
>> On Thu, 28 Jan 2010 22:28:23 +0100, Silvia Pfeiffer
>> <silviapfeiffer1@gmail.com> wrote:
>>
>>> On Thu, Jan 28, 2010 at 11:48 PM, Philip Jägenstedt <philipj@opera.com>
>>> wrote:
>>>>
>>>> On Wed, 27 Jan 2010 23:38:39 +0100, Silvia Pfeiffer
>>>> <silviapfeiffer1@gmail.com> wrote:
>>>>
>>>>> On Wed, Jan 27, 2010 at 11:54 PM, Philip Jägenstedt  
>>>>> <philipj@opera.com>
>>>>>>
>>>>>> 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?
>>>>
>>>> Presumably each spec can decide what is normative and what isn't, but  
>>>> I
>>>> think all content in MF URI is normative unless it is explicitly  
>>>> marked
>>>> otherwise (example, informative, etc). This is my assumption anyway,  
>>>> and
>>>> why
>>>> I marked some quite vague sections with "Note: This section is
>>>> non-normative".
>>>>
>>>> What I would like is more clear requirements and less "specification  
>>>> by
>>>> example" (examples are useful, but should be marked as such). Right  
>>>> now,
>>>> 5.2.1 and 3.2 to which it refers is most in need of this, since they
>>>> *only*
>>>> contain examples and no requirements as far as I can see. If we want  
>>>> to
>>>> require HTTP byte range requests to be used (rather than being  
>>>> protocol
>>>> agnostic, which I would prefer) then a reference to the spec for HTTP
>>>> byte
>>>> ranges would be in order, for example.
>>>
>>> It already has such as reference "In this case, the HTTP exchanges are
>>> exactly the same as for any other Web resource where byte ranges are
>>> requested [RFC 2616]." All the examples are only there to illustrate
>>> the key points. In theory they are not required. Nothing wold need to
>>> be stated other than the two first sentences: UA knows how to map the
>>> URI fragments to byte ranges, see HTTP protocol. This part is
>>> normative - the rest illustration.
>>
>> Oops... I have no excuse for missing that, you are right.
>>
>>> I think we need to keep one thing in mind: the media fragment URI
>>> specification is all about specifying a URI syntax - the rest is just
>>> recommendations on how to resolve it. Nothing beyond the syntax is
>>> really normative. It's just like the URI spec
>>> http://www.ietf.org/rfc/rfc3986.txt, which also only specifies a
>>> syntax and describes how to interpret it - nowhere is the word
>>> normative mentioned there.
>>>
>>> In fact, the whole media fragment spec could be reduced to section 4.
>>> In practice that doesn't help anyone because it doesn't explain
>>> expectations and how it should work with the existing Web. But it's
>>> really all we have been chartered for.
>>
>> OK, fair enough. I will try to not be distracted by the prose sections.  
>> If
>> possible we should mark them with (Informative), I went with "Note: this
>> section is non-normative" only because I couldn't figure out how to do
>> (Informative).
>>
>>>> Finally, since we intend for other specs to refer to this spec, we  
>>>> also
>>>> need
>>>> to have clear hook definitions they can reuse and should also write an
>>>> example of how other specs can refer to ours, unless it's obvious (it
>>>> isn't
>>>> to me at this point).
>>>
>>> It's all about section 4 IMHO. You've already numbered through all the
>>> production rules so IMHO that's already given.
>>>
>>> I'm still struggling to see what you think is missing. You may well be
>>> right, but I haven't really grasped what gaps you have identified. I
>>> think there is enough there for people to know how to implement media
>>> fragment URIs (once finished). No?
>>
>> Most importantly, I don't think section 4 is good enough yet, "even"  
>> after
>> my additions. For example, I can't determine from the spec what effect
>> #t=100 should have on a 50 second resource or what to do with #t=20,10.
>>
>> Speaking as an implementor, I want hard, unambiguous requirements for  
>> which
>> there is a clear pass condition that can be added to a test suite (which
>> this WG must produce, based on the spec and nothing but the spec,  
>> right?).
>
> Yup, this agree with - we haven't actually discussed error cases yet.
> Some of them have gone in and we had a lengthy discussion on what
> error cases there are - even made a nice matrix. I think Michael has
> the details and was going to prepare them.
>
> We should indeed start specifying those. Once we get all that
> information together, we can make changes to the structure. I think
> it's a bit immature to go changing everything now though.

That needs to happen fast, because as soon as a major browser implements  
the temporal syntax they will have done *something* and what usually  
happens is sites will begin depending on that behavior, the browser can't  
change it and the spec has to align, even if we don't like the behavior...

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Thursday, 28 January 2010 23:13:47 UTC