W3C home > Mailing lists > Public > public-media-annotation@w3.org > June 2011

RE: follow up on the discussion in HTML5 about metadata access

From: Joakim Söderberg <joakim.soderberg@ericsson.com>
Date: Wed, 8 Jun 2011 13:33:14 +0200
To: "public-html@w3.org" <public-html@w3.org>
CC: "tmichel@w3.org" <tmichel@w3.org>, Philippe Le Hegaret <plh@w3.org>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Karl Dubost <karld@opera.com>, Leonard Rosenthol <lrosenth@adobe.com>, "public-media-annotation@w3.org" <public-media-annotation@w3.org>
Message-ID: <376A32D52DCEC845B630D7183D2271C21483A6FC41@ESESSCMS0355.eemea.ericsson.se>
Dear all,
I would like to wrap up this discussion by making some remarks on your concerns about our API design, and also invite you to a joint discussion during next TPAC to see if we can coordinate our work better.


1) As discussed in section 3 of the API document we discuss both scenarios implementing the API as a web service and in a user agent. The current example implementations are web service based (see [2]), which correspond to the use case of a media provider using an implementation of the API to publish metadata in the format compliant to the specification. However, we also considered the use case where existing metadata, published in any of the formats considered in the mappings, needs to be accessed by a user agent and processed, possibly together with metadata in other formats. The contributors at University of Passau are currently working on a Firefox plugin implementing the API for that purpose. Unless one assumes the existence of a web service doing the mapping, we think that this use case requires the API and mapping functionality on the client side.

2) The API is not only targeted at browsers, but implementation in the browser is one of the cases. We do agree that interaction with the implementers is crucial, and we have made several attempts to start a discussion with browser vendors, but with little feedback. The fact that the spec does not only target browsers also explains that specific details as mentioned in concern 3 are not included. We would expect that such details go into a separate document, built on top of the API spec.

Best regards,
Joakim Söderberg


[1] http://dev.w3.org/2008/video/mediaann/mediaont-api-1.0/mediaont-api-1.0.html

[2] http://www.w3.org/2008/WebVideo/Annotations/#Implementa


-----Original Message-----
From: public-media-annotation-request@w3.org [mailto:public-media-annotation-request@w3.org] On Behalf Of Henri Sivonen
Sent: den 11 maj 2011 11:06
To: Julian Reschke
Cc: tmichel@w3.org; Philippe Le Hegaret; Silvia Pfeiffer; Karl Dubost; Leonard Rosenthol; public-html@w3.org; public-media-annotation@w3.org
Subject: Re: follow up on the discussion in HTML5 about metadata access

On Wed, 2011-05-11 at 09:50 +0200, Julian Reschke wrote:
> On 11.05.2011 08:01, Thierry MICHEL wrote:
> >
> >
> > And the notion of "valuable" changes over time ....
> > For example SVG 5 years ago, required extra plugin to display in the 
> > Web browsers, in our days it displays natively in most browsers.
> >
> > Who knows, in the future this may happen to SMIL (part our SMIL is 
> > already into browsers) and to Epub ...
> 
> Or PDF.

PDF might become part of the built-in feature set of browsers at some point. Maybe. But it isn't part of the built-in feature set across browsers *now*. Neither is ePub.

I think designing APIs for PDF and ePub should be in the "let's cross the bridge when we get there" department for now. If in the future PDF or ePub becomes part of the interoperable browser platform, the API situation can be reassessed.

Designing APIs now without implementor participation may well be a "wrong tomorrow" exercise that results in a lot of wasted effort, because the requirement are different when it's time to have browser APIs for PDF or ePub (if that day comes). (Consider the browser implementor reaction to W3C Timed Text compared to WebVTT for example.)

--
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/



Received on Wednesday, 8 June 2011 11:33:39 UTC

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