Re: Feedback from FOMS

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

I guess I'll keep editing until I think it's possible to implement without  
guessing or looking for intent in examples or informative prose.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Thursday, 28 January 2010 22:54:23 UTC