W3C home > Mailing lists > Public > public-media-fragment@w3.org > December 2009

Re: Processing requirements

From: RaphaŽl Troncy <Raphael.Troncy@cwi.nl>
Date: Wed, 02 Dec 2009 23:15:41 +0100
Message-ID: <4B16E70D.9020607@cwi.nl>
To: Philip Jšgenstedt <philipj@opera.com>
CC: Jack Jansen <Jack.Jansen@cwi.nl>, Media Fragment <public-media-fragment@w3.org>, Michael Hausenblas <michael.hausenblas@deri.org>
Hi Philip,

Thanks for your email, it contains a lot of food for building the test 
cases suite! Regarding the test suite, please note that we are using the 
Corrib tool setup developed and maintained by Michael, 
http://ld2sd.deri.org/corrib/

We have other test cases documented at 
http://www.w3.org/2008/WebVideo/Fragments/wiki/TestCases that ultimately 
should all go in Corrib once Michael would have completed his actions 
108, 115 and 118 ;-) Philip, do not hesitate to add more nasty test 
cases in the test suite, I think you should be able to do that, could 
you confirm Michael?

Regarding Jack's point:

>> The current ABNF only allows joining timesegment / spacesegment /
>> tracksegment by "&", which means that e.g. #t=5& is not allowed
>> because it has a trailing &, which is very easy to get by accident
>> if you write a script like this:
>> 
>> urifrag = '#': for d in dimensions: urifrag += d + '&'
> 
> I'm not thrilled by this idea. The web has a long history of features
> where an initial implementation was syntactically forgiving because
> it was deemed to be user-friendly at the time. Many of these have
> been causing endless headaches until today. Think of the ability to
> use filenames (especially Windows filenames) in the URL-bar, or in
> attributes in the HTML code. Think of global variables in JavaScript.

I'm not thrilled by the idea either. So far, we have considered that 
invalid Media Fragment URI would trigger a normal HTTP request and the 
entire representation of the resource as HTTP response. But this is not 
yet engraved in stones :-)

> But: I have an idea that may be a solution to this, loosely based on
> the SMIL skip-content attribute
> (http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-content.html#adef-skip-content).
> If we add an attribute that tells older implementations what to do
> (ignore unknown attributes, or raise an error) we could have our cake
> and eat it. The first example would then usually be coded as
> "....&preferred-languages=english-french-german&unknown=ignore", the
> second as "....&rating=pg&unknown=error". The only remaining question
> is now: what is the default value for the unknown attribute.
> 
> What do y'all think? Would this fly?

I like the idea! I understand the 'ignore' case, but we would need to 
agree on what means 'error'. I would vote for the entire representation 
of the resource is returned.
Regarding the default value, we could let the community decide. I think 
I'm inclined to say 'error', i.e. return the entire representation of 
the resource.

   RaphaŽl

-- 
RaphaŽl Troncy
EURECOM, Multimedia Communications Department
2229, route des CrÍtes, 06560 Sophia Antipolis, France.
e-mail: raphael.troncy@eurecom.fr & raphael.troncy@gmail.com
Tel: +33 (0)4 - 9300 8242
Fax: +33 (0)4 - 9000 8200
Web: http://www.eurecom.fr/~troncy/
Received on Wednesday, 2 December 2009 22:16:48 GMT

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