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

Dear Werner,

The background is just that for instance EBU Eurovision can publish some NewsML-g2 snippets on one of our pages for the purpose of the test, which would be accessible through simple http requests. But it seems that this is covered by scenario 2?

Best regards,

Jean-Pierre

-----Original Message-----
From: Bailer, Werner [mailto:werner.bailer@joanneum.at] 
Sent: jeudi, 18. février 2010 13:25
To: Evain, Jean-Pierre; public-media-annotation@w3.org
Subject: RE: ACTION-211: text on client/server implementation of API

Dear Jean-Pierre,

If I understand correctly you are thinking of a metadata extraction/mapping service, that receives metadata documents or media resources from a client and then uses the metadata? That would mean that the metadata document/media resource is not kept at the server, otherwise I think it would just uploading it and then using the API on the server side as it is already covered by scenario 2. Do you have a use case for such a scenario?

Best regards,
Werner

> -----Original Message-----
> From: Evain, Jean-Pierre [mailto:evain@ebu.ch]
> Sent: Donnerstag, 18. Februar 2010 13:09
> To: Bailer, Werner; public-media-annotation@w3.org
> Subject: 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).

-----------------------------------------
**************************************************
This email and any files transmitted with it 
are confidential and intended solely for the 
use of the individual or entity to whom they
are addressed. 
If you have received this email in error, 
please notify the system manager.
This footnote also confirms that this email 
message has been swept by the mailgateway
**************************************************

Received on Thursday, 18 February 2010 12:31:38 UTC