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: Felix Sasaki <felix.sasaki@fh-potsdam.de>
Date: Tue, 26 Jan 2010 16:51:21 +0100
Message-ID: <ba4134971001260751p7446aeccu34c7fb51e56fc67f@mail.gmail.com>
To: Pierre-Antoine <pierre-antoine.champin@liris.cnrs.fr>
Cc: public-media-annotation@w3.org
+1 to all what Pierre-Antoine says. Providing an artificial format for
storing expected results is good, and having it not as the artifical input
format is good too.


2010/1/26 Pierre-Antoine <pierre-antoine.champin@liris.cnrs.fr>

> 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 15:51:54 UTC

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