Re: Asking for feedback on API design from the Web Browser Community

On Tue, 01 Dec 2009 17:39:47 +0100, Joakim Söderberg  
<joakim.soderberg@ericsson.com> wrote:

> Hello Doug,
> As you might remember we had some discussions in Santa Clara about who  
> should implement our API and how. We are considering two places where  
> the API can be used: in the Web-browser or as Web-service (see picture).
>
>
> The current FPWD API (http://www.w3.org/TR/mediaont-api-1.0/ ) defines  
> one function for each core-property, but we probably resort to have one  
> function for all properties:  
> http://lists.w3.org/Archives/Public/public-media-annotation/2009Nov/0072.html
>
>
> For example:
>
> md.get("contributor")
>
>
> - would return a set of values. Those values would basically be text,  
> but would have an optional attribute (call it "role" or
> "subproperty"...) indicating more precisely the kind of contributor  
> represented by the text.
>
>
> Further, recall that we had a vivid discussion about sub-properties.  
> Currently we aim at NOT introducing sub-properties but rather return the  
> inherited sub-properties from the original format. Example:
>
>
> md.getValues("contributor")
> returning
>   [ { "value": "John Doe", "subproperty": "id3:composer" },
>     { "value": "Jane Doe", "subproperty": "id3:lyricist" };
>
> or see:  
> http://lists.w3.org/Archives/Public/public-media-annotation/2009Nov/0081.html
> We would very much appreciate any feedback from your connections in the  
> Web Browser (development) community. Also the naming of this function is  
> important, so as not be in conflict with existing APIs, i.e.  
> getMetadata, md.getValue etc.
> Regards
> Joakim Söderberg

Media Annotations WG,

I've been following this list for quite some time already, but am now also  
a member of the WG. I consider myself part of the "web browser community"  
and have been doing quite a bit of work related to HTML5 <video>. As you  
may or may not know, HTML5 might be needing a way to expose some basic  
information about the tracks of a media file to enable scripts to choose  
between multiple (typically subtitle) tracks.

Some initial feedback:

I am happy that the API hides the complexity of the underlying vocabulary,  
which is not something we want to expose web authors to.

Implementing the API in ECMAScript by raising NoValue when a property  
isn't available isn't an option. Rather you would want return undefined.

I also can't see anything to help the track identification use case HTML5  
may need, as the MediaResource interface seems to treat the resource as a  
single entity. I agree with keeping almost all metadata per-resource, but  
e.g. language and technical details should be per-track.

This is only at a first glance, I will read all 3 documents and get back  
with more feedback in a few weeks.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Wednesday, 2 December 2009 14:17:16 UTC