Re: [mawg] Re: ACTION-177: API at client/server side (was: Call for Test Cases)

2009/11/11 Silvia Pfeiffer <silviapfeiffer1@gmail.com>

> Hi Felix, Werner,
>
> I don't quite follow the discussion.
>
> Let's say we look at the browser case. It will typically use some kind
> of media framework to implement <video> and <audio> element support.
> These support multiple formats. Each format may have different
> metadata, but the media framework will implement access functions for
> this metadata.



Ah, OK. That point "the media framework will implement access functions for
this metadata" I was not sure about. There are some formats which we have in
scope (e.g. XMP), but which provide no platform-unspecific media framework /
access functions. How would you deal with these?

Best,

Felix



> Those functions can be hooked up to the javascript
> function that we are defining here, i.e. the browser implements the
> mapping that we are defining here from the native metadata property to
> the interface that it is required to expose to javascript. This is the
> expected work and it's not overly hard.
>
> Cheers,
> Silvia.
>
>
> On Wed, Nov 11, 2009 at 11:28 PM, Felix Sasaki
> <felix.sasaki@fh-potsdam.de> wrote:
> > OK. I understand your opinion, and agree to some extend. The burden of
> > implementing the appropriate APIs can be very high. But some people,
> maybe
> > Silvia, may expect such APIs.
> >
> > Best,
> >
> > Felix
> >
> > 2009/11/11 Bailer, Werner <werner.bailer@joanneum.at>
> >>
> >> As we discussed from the beginning on, we consider the development of
> >> these API not in scope of our group, but we use whatever existing APIs
> are
> >> available for extracting metadata from a media resource or parse a
> metadata
> >> format, and integrate these into our API implementation.
> >>
> >> I'm not sure if there should be a common interface between an API
> >> implementation and all the format specific APIs. I think this is just
> >> deferring the problem one layer, because such an interface would not be
> so
> >> different from the API we are defining. So an implementation that deals
> with
> >> format X has to take the burden of integration an appopriate API for
> >> accessing format X.
> >>
> >> This is my opinion on that issue, other comments are welcome.
> >>
> >> Best regards,
> >> Werner
> >>
> >> ________________________________
> >> Von: felix.sasaki@googlemail.com [felix.sasaki@googlemail.com] im
> Auftrag
> >> von Felix Sasaki [felix.sasaki@fh-potsdam.de]
> >> Gesendet: Mittwoch, 11. November 2009 12:39
> >> An: Bailer, Werner
> >> Cc: Pierre-Antoine; public-media-annotation@w3.org
> >> Betreff: Re: [mawg] Re: ACTION-177: API at client/server side (was: Call
> >> for Test Cases)
> >>
> >> Many thanks for the explanation, Werner. Another question: you wrote in
> a
> >> reply to Silvia about access to metadata:
> >>
> >> "Yes, that's why there are 2 paths in the diagram: from the metadata
> >> document via a format specific API, and/or from the media resource via
> an
> >> extractor and possibly also a format specific API."
> >>
> >> Who is working on the format-specific extractors, or to put it
> >> differently: how is the "common interface to all of these!" being
> realized?
> >>
> >> Best,
> >>
> >> Felix
> >>
> >> 2009/11/11 Bailer, Werner
> >> <werner.bailer@joanneum.at<mailto:werner.bailer@joanneum.at>>
> >> Hello Felix,
> >>
> >> we have created an action for Chris to propose a WebIDL notation for the
> >> function. Probably the arguments of the function will not change much to
> >> what we have, only that there is a first mandatory argument with the
> >> property name. As we need now a more general return type, this change
> would
> >> probably resolve some of our issues with the return types, as we will
> always
> >> get back a more or less self descriptive list of values.
> >>
> >> The idea is then to request further feedback from browser vendors before
> >> we go ahead and implement the changes in the API document.
> >>
> >> Best regards,
> >> Werner
> >>
> >> ________________________________
> >> Von: felix.sasaki@googlemail.com<mailto:felix.sasaki@googlemail.com>
> >> [felix.sasaki@googlemail.com<mailto:felix.sasaki@googlemail.com>] im
> Auftrag
> >> von Felix Sasaki
> >> [felix.sasaki@fh-potsdam.de<mailto:felix.sasaki@fh-potsdam.de>]
> >> Gesendet: Mittwoch, 11. November 2009 12:18
> >> An: Bailer, Werner
> >> Cc: Pierre-Antoine;
> >> public-media-annotation@w3.org<mailto:public-media-annotation@w3.org>
> >> Betreff: Re: [mawg] Re: ACTION-177: API at client/server side (was: Call
> >> for Test Cases)
> >>
> >> Hello Werner,
> >>
> >> sounds all very reasonable arguments to me. Is there a proposal for the
> >> structure of the function, and how will it relate to the API
> descriptions we
> >> have already? Maybe you can answer the question on a prototypical
> example
> >> like the "creator" property
> >> http://www.w3.org/TR/mediaont-api-1.0/#creators
> >>
> >> Thanks,
> >>
> >> Felix
> >>
> >> 2009/11/11 Bailer, Werner
> >> <werner.bailer@joanneum.at<mailto:werner.bailer@joanneum.at><mailto:
> werner.bailer@joanneum.at<mailto:werner.bailer@joanneum.at>>>
> >> Dear Pierre-Antoine,
> >>
> >> we had a discussion about this issue at the F2F, triggered by comments
> >> from Doug Schepers. The arguments for having one function are
> >>
> >> - browser vendors only need to implement one function to support the API
> >> - it might be convenient for web developers to query several properties
> by
> >> defining an array with property names and iterate over it
> >> - extensibility, both to new properties, but also wrt to subtypes, e.g.
> >> when we define a subtype "albumTitle" of title one could directly query
> for
> >> it, instead of using a filter on getTitle
> >>
> >> Best reagrds,
> >> Werner
> >>
> >> ________________________________________
> >> Von:
> >> public-media-annotation-request@w3.org<mailto:
> public-media-annotation-request@w3.org><mailto:
> public-media-annotation-request@w3.org<mailto:
> public-media-annotation-request@w3.org>>
> >> [public-media-annotation-request@w3.org<mailto:
> public-media-annotation-request@w3.org><mailto:
> public-media-annotation-request@w3.org<mailto:
> public-media-annotation-request@w3.org>>]
> >> im Auftrag von Pierre-Antoine
> >> [pierre-antoine.champin@liris.cnrs.fr<mailto:
> pierre-antoine.champin@liris.cnrs.fr><mailto:
> pierre-antoine.champin@liris.cnrs.fr<mailto:
> pierre-antoine.champin@liris.cnrs.fr>>]
> >> Gesendet: Montag, 09. November 2009 21:36
> >> An: Silvia Pfeiffer;
> >> public-media-annotation@w3.org<mailto:public-media-annotation@w3.org
> ><mailto:public-media-annotation@w3.org<mailto:
> public-media-annotation@w3.org>>
> >> Betreff: Re: [mawg]  Re: ACTION-177: API at client/server side (was:
> Call
> >>  for Test Cases)
> >>
> >> Le 08/11/2009 03:43, Silvia Pfeiffer a écrit :
> >> > BTW: re javascript API: It should be a small number of functions, not
> >> > one per property ("getTitle" seemed to indicate to me that there was a
> >> > particular API function for it). If it turns out you need more than
> >> > one, that's fine. Just not one per property (which, incidentally, is
> >> > also more extensible).
> >>
> >> except for the point of extensibility, which I understand, could you
> >> elaborate on the rationale for "Just not one per property"?
> >>
> >> Although there has to be a generic function for the sake of
> >> extensibility, I think the general feeling of the group was that it is
> >> more convenient for a developer to write
> >>  getTitle(...)
> >> than
> >>  getProperty("title", ...)
> >>
> >>  pa
> >>
> >> >
> >> > I will keep watching the progress of the group - I am also subscribed.
> >> >
> >> > Thanks,
> >> > Silvia.
> >> >
> >> >
> >> > On Fri, Nov 6, 2009 at 7:08 PM, Bailer, Werner
> >> >
> >> > <werner.bailer@joanneum.at<mailto:werner.bailer@joanneum.at><mailto:
> werner.bailer@joanneum.at<mailto:werner.bailer@joanneum.at>>>
> >> > wrote:
> >> >> Dear Silvia, all,
> >> >>
> >> >> thanks for your mail, you are asking a very good question. In fact,
> we
> >> >> discussed about that yesterday before you joined, resulting in an
> action to
> >> >> visualise the options we discussed.
> >> >>
> >> >> Attached is a sketch showing two options:
> >> >>
> >> >> 1. implementation as Javascript interface in the browser, requiring
> >> >> also all the functionality for extracting metadata from the source
> formats
> >> >> and for mapping there (I think this is the option you are discussing
> in your
> >> >> mail)
> >> >>
> >> >> 2. implementation as a web service, accessing either remote or local
> >> >> (e.g. database of a portal in proprietary format) media resources and
> >> >> metadata, there could be an (optional) Javascript library that
> provides the
> >> >> same API interfaces and handles the calls to the web service
> >> >>
> >> >> Feedback is of course highly welcome.
> >> >>
> >> >> Concerning the two proposals:
> >> >>
> >> >> - single function: no final decision, but it is very to likely
> >> >>
> >> >> - other formats: we have already done the mappings for QuickTime, we
> >> >> should do it for the others you mentioned
> >> >>
> >> >> Best regards,
> >> >> Werner
> >> >>
> >> >> ________________________________________
> >> >> Von:
> >> >> public-media-annotation-request@w3.org<mailto:
> public-media-annotation-request@w3.org><mailto:
> public-media-annotation-request@w3.org<mailto:
> public-media-annotation-request@w3.org>>
> >> >> [public-media-annotation-request@w3.org<mailto:
> public-media-annotation-request@w3.org><mailto:
> public-media-annotation-request@w3.org<mailto:
> public-media-annotation-request@w3.org>>]
> >> >> im Auftrag von Silvia Pfeiffer
> >> >> [silviapfeiffer1@gmail.com<mailto:silviapfeiffer1@gmail.com><mailto:
> silviapfeiffer1@gmail.com<mailto:silviapfeiffer1@gmail.com>>]
> >> >> Gesendet: Samstag, 07. November 2009 01:11
> >> >> An: Joakim Söderberg
> >> >> Cc:
> >> >> public-media-annotation@w3.org<mailto:public-media-annotation@w3.org
> ><mailto:public-media-annotation@w3.org<mailto:
> public-media-annotation@w3.org>>
> >> >> Betreff: Re: Call for Test Cases
> >> >>
> >> >> Hi all,
> >> >>
> >> >> I was going to ask some questions that emerged over the last hour,
> but
> >> >> unfortunately it seems the group has finished meeting.
> >> >>
> >> >> I have a question about where you are going to use the API that
> you're
> >> >> defining. One suggestion that I heard was as a javascript interface
> to
> >> >> the metadata available in a video/audio file referenced in a <video>
> >> >> or <audio> element of HTML5.
> >> >>
> >> >> Is this indeed something you are contemplating?
> >> >>
> >> >> In this case, it would be great to have:
> >> >> * a single function and not multiple to access the metadata,
> >> >> and
> >> >> * analysis of the metadata used in to QuickTime, Ogg, MPEG4, FLV and
> >> >> whether it matches with the API.
> >> >>
> >> >> I'd be happy to help promote the generic function into HTML5 when the
> >> >> spec is finalised.
> >> >>
> >> >> Cheers,
> >> >> Silvia.
> >> >>
> >> >>
> >> >> 2009/11/6 Joakim Söderberg
> >> >> <joakim.soderberg@ericsson.com<mailto:joakim.soderberg@ericsson.com
> ><mailto:joakim.soderberg@ericsson.com<mailto:
> joakim.soderberg@ericsson.com>>>:
> >> >>> Hello everyone,
> >> >>>
> >> >>> As a result of the 5th F2F meeting in Santa Clara we have started to
> >> >>> define
> >> >>> our test suite
> >> >>> requirements
> >> >>> (http://www.w3.org/2008/WebVideo/Annotations/wiki/TestSuite).
> >> >>> We kindly ask the workgroup participants for some more example test
> >> >>> cases!
> >> >>> We came up with some example test cases:
> >> >>>
> >> >>> 1) getTitle
> >> >>> The API should deal with the situation that
> >> >>>  1) there is no title
> >> >>>  2) there are multiple titles (that all come from different metadata
> >> >>> formats)
> >> >>>  3) multiple types of title (such as Album title, Song title)
> >> >>>
> >> >>> 2) Make sure that the API can get additional metadata that are
> >> >>> referred to
> >> >>> in the embedded metadata
> >> >>> ex. An XMP description referring to another metadata document ( a
> >> >>> license
> >> >>> etc.)
> >> >>> 3) For the Ontology
> >> >>> Take two metadata resources that represent the same thing and make
> >> >>> sure that
> >> >>> the API return the same values.
> >> >>>
> >> >>> 4) Write something in the wrong way, fake a metadata format that is
> >> >>> not
> >> >>> valid with a metadata specification and see what the API should do
> >> >>> with it,
> >> >>> return in anyway, or not return it at all.
> >> >>>
> >> >>> 5) Combination example
> >> >>> Get the value of the title and then filter
> >> >>>
> >> >>> Asking for a generic property like title, then filter the result to
> >> >>> get just
> >> >>> the album title,
> >> >>> and second directly ask for Album title and compare the results.
> >> >>>
> >> >>> See more at:
> >> >>> http://www.w3.org/2008/WebVideo/Annotations/wiki/TestSuite
> >> >>> Regards
> >> >>> Joakim Söderberg
> >> >>>
> >> >>
> >> >>
> >> >
> >>
> >>
> >>
> >
> >
>