[MF-TC] Setup


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

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?

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

 + 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

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

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

+ 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?


[1] http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/72
[2] http://www.w3.org/2008/WebVideo/Fragments/wiki/TestCasesOverview
[3] http://www.w3.org/2008/WebVideo/Fragments/wiki/TestCases
[5] http://www.w3.org/2008/WebVideo/Fragments/wiki/HTTP_implementation
[6] http://www.w3.org/2008/WebVideo/Fragments/wiki/RTSP_implementation

Dr. Michael Hausenblas
DERI - Digital Enterprise Research Institute
National University of Ireland, Lower Dangan,
Galway, Ireland, Europe
Tel. +353 91 495730

Received on Sunday, 19 April 2009 12:05:34 UTC