- From: Jack Jansen <Jack.Jansen@cwi.nl>
- Date: Tue, 14 Apr 2009 15:09:44 +0200
- To: Raphaël Troncy <Raphael.Troncy@cwi.nl>
- Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Media Fragment <public-media-fragment@w3.org>
On 13 apr 2009, at 23:42, Raphaël Troncy wrote: > Dear Silvia, > > [I suspect Jack has already addressed some of these comments, but I > made another run :-)] Nope, I hadn't: it was still easter here. Thanks for fixing these! I made a quick pass and fixed one other minor one. These require discussion, however: > >> Section 6.4, Second Editorial Note >> * we should specify that if named addressing is used, all others >> are ignored > > I added: > "Incompatible: if the named dimension is used, all the other > dimensions are ignored." > >> * we should specify that if multiple temporal or spatial or track >> parameters are used, only the first one is interpreted > > Partially captured by the semantic error #1, slightly rephrased. > >> * we should specify that any dimensions specified outside the media >> resource (e.g. end time after end of file, coordinates outside the >> frame) are to be clipped to the actual size of the resource > > Partially captured by the semantic error #3 in the ed note, but I > have completed it. > >> * we should specify that unknown id or unknown track specifier are to >> result in no-op > > Captured by the semantic error #2 in the ed note. > >> * we should specify that non-sensical time specs or coordinates (e.g. >> t=20,10) result in no-op > > Captured by the semantic error #4. > Thanks for the carreful reading. The question boils down to what our preferred error treatment is: masking the error and attempting to continue or flagging it. My preference is that hard syntax errors are flagged (such as overspecifying a dimension, or specifying both name and something else), and soft errors, which depend on the underlying media item, are masked. -- Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman
Received on Tuesday, 14 April 2009 13:10:29 UTC