W3C home > Mailing lists > Public > public-media-fragment@w3.org > January 2010

Re: Feedback from FOMS

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 29 Jan 2010 14:17:46 +1100
Message-ID: <2c0e02831001281917k472b1848x35e6256d180d0e13@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: Media Fragment <public-media-fragment@w3.org>
On Fri, Jan 29, 2010 at 10:12 AM, Philip Jägenstedt <philipj@opera.com> wrote:
> 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...

I agree.

At the last meeting, Michael promised he'd have something by next week
- seems this should be a major focus of our next week's meeting. These
are Michael's relevant actions on this:
* ACTION-108: Michael to add the missing test cases in corrib
* ACTION-115: Michael to come up with categorization of test cases wrt
empty, undefined, etc
* ACTION-118: Michael to come up with individual 'normal' test cases (+/-20)

Maybe if something was circulated beforehand, we could all contribute
and make sure the list is complete, at least for the temporal axis?

Received on Friday, 29 January 2010 03:18:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:44 UTC