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: Bailer, Werner <werner.bailer@joanneum.at>
Date: Tue, 26 Jan 2010 17:01:12 +0100
To: Pierre-Antoine <pierre-antoine.champin@liris.cnrs.fr>, "public-media-annotation@w3.org" <public-media-annotation@w3.org>
Message-ID: <CD9846F872C7874BB4E0FDF2A61EF09F4DADB12E04@RZJC1EX.jr1.local>
+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 Tuesday, 26 January 2010 16:01:45 UTC

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