W3C home > Mailing lists > Public > public-media-annotation@w3.org > February 2010

Re: Comments on "API for Media Resource 1.0"

From: <Chris.Poppe@elis.UGent.be>
Date: Tue, 23 Feb 2010 14:32:37 +0100
Message-ID: <20100223143237.19752ujbrof7in79@mail.elis.ugent.be>
To: Dominique Hazael-Massieux <dom@w3.org>
Cc: public-media-annotation@w3.org
Dear Dominique,

thanks a lot for your comments! Please see my answers/thoughts inline ([CP])

Kind regards,


Ghent University - Multimedia Lab
Sint-Pietersnieuwstraat 41
B-9000 Ghent, Belgium

tel: +32 9 264 89 17
fax: +32 9 264 35 94
e-mail: Chris.Poppe@ugent.be

URL: http://multimedialab.elis.ugent.be/chpoppe

Quoting Dominique Hazael-Massieux <dom@w3.org>:

> Hi,
> A few comments based on a quick review of "API for Media Resource 1.0"
> http://www.w3.org/TR/2009/WD-mediaont-api-1.0-20091020
> Checking the WebIDL declaration using the WebIDL checker [1], I've found
> the following bugs in the WebIDL: constant (in the exception
> declarations) cannot take DOMString as types (only float, integers and
> booleans).
> (note that I had to copy & paste the IDL in the checker to verify it �
> it would be great if the <pre> that encompasses the WebIDL declaration
> could use a class="idl" which would make it possible for the checker to
> detect it directly in the document itself)

[CP] the use of exceptions has been changed in the new version. Note  
that we have based ourselves on the last editors draft of WebIDL [1]  
and it seems that the WebIDL checker does not conform with this spec  
(for instance the T[] arrays are not accepted). We will take the  
class-tag into account in our next version.

[1] http://dev.w3.org/2006/webapi/WebIDL/

> But beyond purely syntactic considerations, the current proposed API
> seem very awkward compared to most JavaScript APIs I know of; a few
> examples of these awkwardnesses:
> � using exceptions on every attribute declaration makes it really hard
> to program (you need a try {} catch {} block each time you access the
> said attribute); it would be much more natural to use nullable
> attributes
> http://dev.w3.org/2006/webapi/WebIDL/#idl-nullable-type

[CP]We agree with this remark and it has been uttered before. As such  
the use of exceptions has been replaced by appropriate return values.

> � given that you define a "Contributors" interface (which really should
> be "Contributor"), why isn't MediaResource.contributors of the type
> Contributors[] (rather than object[])? This applies to the other
> attributes with the object and object[] types

[CP]We agree that the Contributor interface does not need to be  
plural. Additionally, your remark on the use of object[] is a good  
one, in the new version of the document we use an operation which  
gives back object[]. In this case the arguments of the operation  
determin the kind of objects that are returned in the array.

> � EcmaScript5 defines a Date object, which you really should consider
> using instead of defining a new interface

[CP] I agree that we should use an existing representation. However,  
currently Web-IDL does not include ways to describe a Date. The  
working draft does hold an editorial note about HTML5 Date and the use  
of java.util.Date or EcmaScript Date. Do you have any idea on the  
direction which will be followed?

> � unless you expect structured data to be available for the location
> attribute, I would suggest using a DOMString rather than a specific
> object; if you really want a Location interface, the DAP and Geolocation
> WGs have been working on one

[CP]Interesting remark. We are currently discussing what can be  
represented by the location attribute (e.g. name of a place: "my  
house", name of a city, the address of a place, and coordinates). I  
believe that all of these alternatives can be described in some of the  
metadata standards that we have in our scope. So just using a  
DOMString might be to restrictive.
We should indeed check whether the work by the DAP and GeoLocation WGs  
can be used for this.

> � the duration of media resource should probably be expressed in
> miliseconds rather than seconds (since second seem to lack the typical
> kind of granularity one might be expecting at the programmatic level)

[CP] Yes, we did not get feedback on the unit to be used for  
durations, but your argument makes sense.

> There is a pretty strong overlap between that work and some of the work
> in the DAP Working Group (e.g. the Capture API, the possible Gallery
> API), so I would suggest asking a review from the DAP Working Group much
> earlier than at last call.

[CP] I agree and will contact a chair of our group to establish the  
communication on this.

> HTH,
> Dom
> 1. http://www.w3.org/2009/07/webidl-check

This message was sent using IMP, the Internet Messaging Program.
Received on Tuesday, 23 February 2010 13:33:16 UTC

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