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?

Cheers,
Silvia.
Received on Friday, 29 January 2010 03:18:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:37 GMT