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, 

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 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 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:43 UTC