Re: [MF-TC] Setup

Michael,

> As of my ACTION-72 [1] I have now set up the Test Cases as discussed at the
> Barcelona F2F, see [2] for an overview and motivation and [3] for the actual
> test cases (MF-TC), where we gonna review and approve them (for now).

Thanks for this kick-off!
As discussed today during the telecon, these are my comments on the test 
cases:
   - It is not captured by the syntax (Yves said it would be to 
complicated to represent it) but we agreed that in the case of a 
timesegment, no value means the start time (resp. the end time) of the 
resource.
   - I suggest to rename the 'ALL' output value by 'ENTIRE'
   - Consequently, TC0001 is false ans should be labeled 'complete time 
segment - npt' and return ALL instead of NULL. => I have updated the 
wiki accordingly
   - Consequently (bis), I also disagree with the output of TC0007. Note 
also that you cannot have #t=,&id='ID0'. Again something not captured by 
the formal syntax but more generally in the surrounded text at 
http://www.w3.org/2008/WebVideo/Fragments/wiki/Syntax where it is stated:
"combination of the dimensions: id XOR (time, space, track)" (note the XOR).
   - The ',' is mandatory in case a time segment is specified, 
consequently, TC0008 is not a legal media fragment URI. The output 
should be: the whole resource is sent and the UA seeks to 10s.

The various empty time/segment/track/id test cases need indeed to be 
further discussed.

> I encountered the following issues while implementing this:
> 
>  + While it is straight-forward to come up with empty MF, I did not find a
> way to express the entire resource given that a namesegment or axissegment
> is present. Thoughts anyone?

Yes, you did :-)
TC0001 actually captures the whole video.

>  + TC0008, though desirable, will currently fail due to our MF Grammar

Yes.
Actually, TC0008 and TC0009 captures the same thing ... i.e., do not 
break the current behavior of the hash when one does not enter the media 
frag URI syntax.

>  + When implementing TC0009 I found this hard to express without saying
> something about the media type (that is, IMO we need an additional field
> that defines the targeted media type). As you know, the semantics of the URI
> fragment are media type dependent, hence this shouldn't take us any wonder
> ;)

Would you then mean create a new property in your RDF vocab for stating 
the mime-type? Would you then mean having for each mime-type, all the 
TC? This will become a combinatory explosion!
Or do you just need to distinguish between audio/*, video/* and images/*?

> + CLASS1 and CLASS2 TC are HTTP-specific and can only be implemented once we
> have agreed on the actual network communications (which header fields, etc.)

Yep, thus waiting for discussing Conrad's proposal.

> + There will certainly be other classes of TC that will address the RTSP
> case

Yes.

> + In the overview [1] I sort of contemplate about a partitioning. The
> proposal currently on the table is to split into:
> 
>  1. Client-side processing (see 'User Agent Media Fragment Resolution and
> Processing' [4])
>  2. Network communication (for HTTP [5] and RTSP [6])
>  3. Server-side processing
> 
> My question now is: is this desirable, that is, keep 2. and 3. separate OR
> does the MF-WG rather think this should be merged?

My personal opinion is that 2. should fall in 3., i.e. have the 
client-side processing and the server-side processing labels. The 
network is in the middle, and I think its point of view is not worth 
being represented.

   Raphaël

-- 
Raphaël Troncy
CWI (Centre for Mathematics and Computer Science),
Science Park 123, 1098 XG Amsterdam, The Netherlands
e-mail: raphael.troncy@cwi.nl & raphael.troncy@gmail.com
Tel: +31 (0)20 - 592 4093
Fax: +31 (0)20 - 592 4312
Web: http://www.cwi.nl/~troncy/

Received on Wednesday, 29 April 2009 14:02:48 UTC