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

Re: ACTION-158: Exhaustive list of Test Cases for the temporal dimension in the Media Fragment URI

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 31 Mar 2010 23:04:36 +1100
Message-ID: <w2p2c0e02831003310504ka07c6f23n21a4d6ed86da424e@mail.gmail.com>
To: Raphal Troncy <raphael.troncy@eurecom.fr>
Cc: Media Fragment <public-media-fragment@w3.org>
Hi Raphael,

2010/3/31 Raphal Troncy <raphael.troncy@eurecom.fr>:
>
>> Also, there are test cases
>> missing for a and b being before the beginning of the media resource.
>> Did you go through all the test cases that I listed in
>>
>> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#error-temporal
>> ?
>
> Let's see:
> . 6.2.1 is equivalent to Test n26, 27a and 27b

Yup, OK.

> . 6.2.2 is equivalent to Test n4 except we don't know if we should return
> a 416 or a 200 ... while you wrote it should be 200

I think we may generally actually have to deal with both error codes
for some requests, and none for others.

If the UA is resolving it all without the help of the server, then
there should never be an error code coming from the server and it
would make little sense for the UA to pretend that such an error code
exists.

Only where we actually pretend as a UA that the request makes sense
and package it in a Range request should we see such a problem.

Specifically for the case of 6.2.2 it would make sense for the UA to
notice that a>b and not even try to do a retrieval action. It should
simply just do nothing, just like a request for a fragment on a HTML
page where the fragment doesn't exist leads to no action.

> . 6.2.3 is equivalent to Test n1

OK.

> . 6.2.4 is equivalent to Test n2 and 3 except that we return a 416 and not
> 200

See reasoning above for no HTTP activity and therefore no return code.


> . 6.2.5 is equivalent to Test n10, 11 and 12 except that we return 206 or
> 416 and not 200

10, 11 and 12 have to be diversified based on whether a lies before or
after the beginning of the media resource. In fact, we need to
introduce something like s=start time and e=end time everywhere. Thus
we need to adapt/introduce the following:

no5: t=a,b with s<=a, a<b, b<=e  => play a to b
introduce no5a: t=a,b with a<s, a<b, s<b, b<=e => play s to b
introduce no5b: t=a,b with a<s, a<b, b<s, b<=e => empty fragment
(these include no6 now)

no7: t=a,b with s<=a, a<b, a<e, b>e => play a to e
no7a: t=a,b with a<s, a<b, a<e, b>e => play s to e
no7b: t=a,b with a<b, a=>e, b>e => empty fragment
(this last one includes no8 and no9)

no10: t=a, with a>=s, a<e => play a to e
no10a: t=a, with a<s, a<e => play s to e

no14: t=,a with a>s, a < d => play s to a
no14a: t=,a with a<=s, a<d => empty fragment


> . 6.2.6 is equivalent to Test n5, 6, 7, 8, 9, 13, and 14 except again you
> always return a 200 while it is often a 206.

Yeah, that's possible where we actually do a HTTP Range request.


> In summary, I found our table much more complete. We differ in the response
> code we should answer. I don't see which test cases we have forgotten. Could
> you please tell me which ones are missing?

Yup, listed above as a/b numbers and additional conditions to the ones
in the existing list. Mostly related to missing out on defining the
"start" time of the resource.

Regards,
Silvia.
Received on Wednesday, 31 March 2010 12:05:30 GMT

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