RE: ACTION-211: text on client/server implementation of API

Dear Werner, all,

I guess there will be another section for the case where the API is on the server side and fetches files from the client using e.g. xmlHTTPrequests?

Best regards,

Jean-Pierre

-----Original Message-----
From: public-media-annotation-request@w3.org [mailto:public-media-annotation-request@w3.org] On Behalf Of Bailer, Werner
Sent: mardi, 16. février 2010 20:49
To: public-media-annotation@w3.org
Subject: ACTION-211: text on client/server implementation of API

Dear all, 

Please find below a first draft of the text describing the client/server scenarios for the API. It might fit into section 2.1 (design considerations) of the API document.

Best regards,
Werner



We consider two scenarios where the API could be implemented: either in the user agent (scenario 1) or as a web service (scenario 2). The two scenarios are shown in Figure XX. 

1. User agent

The API is implemented in the user agent and exposed as a JavaScript API (using the WebIDL JavaScript binding). The user agent includes the components for metadata access (possibly extraction) and mappings for a supported set of formats. The metadata sources (the media resource and/or metadata document(s)) must be retrievable and access to them is handled by the user agent.

2. Web service

The API is implemented as a Web service. 
[Editorial note: there is no appropriate WebIDL binding (such as WSDL), thus appropriate formats for method calls (e.g. HTTP query parameters) and return values (XML, Jason) need to be defined]
Such an implementation would be typically used by a non-UI client, such as an agent harvesting metadata. However, the API could be also accessed from a user agent, and a JavaScript library for accessing the service could be provided, so that the client-side use could be the same as in scenario 1. At the back-end of the web service, this scenario also allows supporting a media repository (e.g. content provider's archive database, movie store) from which the user agent could directly retrieve metadata sources and which might have a custom metadata format not supported by a user agent. An implementation of the API in a web service could do more complex mappings on the fly as a component integrated in a user agent, and can be more flexible, as additional formats are easier to add.

In both scenarios, the access to the metadata properties needs the following stack of components:
- An implementation of the API for Media Resource (as defined in this document), which providers the actual getter methods for the properties.
- An implementation of the mappings from a specific source format to the properties of the media ontology (as defined in Ontology for Media Resource 1.0).
- A format specific API to access the metadata. This is can be an API for accessing a metadata document describing a media resource (e.g. an XML parser and a set of XPath statements) or an extractor the read metadata embedded in the media resource (e.g. a library to read EXIF information from JPEG images). In order to define the context on which the API for Media Resource is working (cf. Section 2.2), it is assumed that there is at least a unidirectional reference from the media resource to the metadata document or vice versa. If this is not the case such a reference needs to be provided by the web application (scenario 1), web service (scenario 2) or media repository (scenario 2).

Received on Thursday, 18 February 2010 12:09:52 UTC