W3C home > Mailing lists > Public > public-media-annotation@w3.org > January 2010

RE: [mawg] RE: Testsuites importants point wrap-up and post on the mailing list

From: Joakim Söderberg <joakim.soderberg@ericsson.com>
Date: Wed, 27 Jan 2010 15:11:19 +0100
Message-ID: <4055256AED9D224D9442B19BF1C4C49004DA4814@esealmw118.eemea.ericsson.se>
To: "Bailer, Werner" <werner.bailer@joanneum.at>, "Pierre-Antoine" <pierre-antoine.champin@liris.cnrs.fr>, <public-media-annotation@w3.org>
Great, now we got the discussion going!

Werner/Jean-Pierre, can you please explain and exemplify how the input would look like?


-----Original Message-----
From: public-media-annotation-request@w3.org [mailto:public-media-annotation-request@w3.org] On Behalf Of Bailer, Werner
Sent: den 26 januari 2010 17:01
To: Pierre-Antoine; public-media-annotation@w3.org
Subject: RE: [mawg] RE: Testsuites importants point wrap-up and post on the mailing list

+1 to Pierre-Antoine

If we go for a web based implementation of the test suite, it could be a service that takes key/value pairs of the properties extracted from the container file as input. This eliminates the need of having an artificial format as input. As Pierre-Antoine suggested, providing the values of the properties that are expected to be extracted from a certain input file is very useful for debugging.

Best regards,

> -----Original Message-----
> From: public-media-annotation-request@w3.org [mailto:public-media- 
> annotation-request@w3.org] On Behalf Of Pierre-Antoine
> Sent: Dienstag, 26. Jänner 2010 15:36
> To: public-media-annotation@w3.org
> Subject: Re: [mawg] RE: Testsuites importants point wrap-up and post 
> on the mailing list
> On 26/01/2010 14:41, Joakim Söderberg wrote:
> > II) Regarding testing the individual features, we can either:
> >
> > 1)      Create some media files corresponding to the formats in
> scope,
> > that contain metadata in that format. E.g. a jpg-file, with EXIF 
> > elements, an mp3 with ID3 etc.
> as Raphael pointed out, depending on the format, this won't be a 
> *media file*, but rather a metadata file (e.g. MPEG-7).
> > BUT then we will have to recommend a library (or other tool) to 
> > extract the metadata, since it should not be part of the test.
> I'm not too sure about that; is it very relevant for us to commit 
> (even
> informally) to a particular software/library? Furthermore, the library 
> depends on the programming language...
> >             2)   Or we produce a text or XML  (1)  file containing
> the
> > native metadata elements and let it represent the metadata in 
> > assumed media file.E.G: <exif:INAM>Eiffel Tower</exif:INAM>
> >
> >             An implementation reads the file, gets the relevant 
> > attribute and returns the correct "ma:" result.
> As I pointed out, I think such a solution would be vain or even 
> counter-productive, as it would require implementations to be able to 
> parse this artificial format, which would not be used outside our test 
> suites. Furthermore, what would guarantee that an implementation 
> passing the test with the artificial format would *also* behave 
> correctly with embeded metadata?
> However, I think that providing such files would be a good idea, but 
> for a different reason: they would help implementors to check that 
> their implementation extract the legacy metadata in a way which is 
> consistent with what we expect. This would *not* be a part of the test 
> (as it would only test the extraction library, not the ma: mapping), 
> but this would definitely help implementors to understand what is 
> wrong if their implementation fails a test -- help them debug the 
> implementation or help us debug the test suite, as we may err in our 
> making of the media/metadata files...
>   pa
Received on Wednesday, 27 January 2010 14:12:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:36 UTC