- From: Raphaël Troncy <Raphael.Troncy@cwi.nl>
- Date: Wed, 02 Dec 2009 23:15:41 +0100
- 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 UTC