- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Mon, 30 Nov 2009 11:21:26 +0100
- To: "richard.tibbett" <richard.tibbett@orange-ftgroup.com>
- Cc: public-device-apis <public-device-apis@w3.org>
Hi Rich, Here come a few comments on the current editors draft [1] of the Contacts API; I think the questions are likely to apply to other APIs in the future, so hopefully looking at them now will help for later too. ⢠all the interfaces defined in the API are annotated with [NoInterfaceObject] [2] ; I think itâs may make sense for the Contacts interface depending on the mechanism used to secure the access to the addressbooks, itâs probably not appropriate for many of the other interfaces; for instance, I donât see how one would add a contact right now, since one cannot instantiate the Contact interface; was there a rationale for hiding the interface object? Maybe some of the interfaces can/should remain hidden through convenience functions, but theyâre not defined in the API right now ⢠assuming the Contact interface becomes instantiable, it would probably need a constructor with a non-optional formatted name parameter? ⢠should there be convenience-functions to add/remove elements to the sequence properties in Contact that are more than just DOMString? ⢠I think all the attributes in Contact but ânameâ should be annotated with a â?â since they are optional [3]; likewise, all the attributes in ContactName should be marked with â?â but âformattedâ ⢠I think the ContactAddress interface should mark as an editors note or as an issue the possible relation to the work in Geolocation v2: http://dev.w3.org/geo/api/spec-source-v2.html#address_interface I think weâll want to converge with it over time; note that they define it as read-only since in their case they exchange immutable objects, but we would clearly need a mutable one [side note: I wonder if thatâs something that would be better defined as property of a specific instance rather than hardcoded in the interface, but I donât think WebIDL allows for this currently] ⢠I am a bit nervous about using SQL as the formal language to describe the filtering algorithm; I think given that the filtering weâre doing is rather simple (OR / AND / LIMIT / OFFSET), I would go with a prose or mathematical description on the set of known contacts. Dom 1. http://dev.w3.org/2009/dap/contacts/ More specifically, v1.13 http://dev.w3.org/cvsweb/~checkout~/2009/dap/contacts/Overview.html?rev=1..13&content-type=text/html;%20charset=utf-8 2. http://dev.w3.org/2006/webapi/WebIDL/#NoInterfaceObject 3. http://dev.w3.org/2006/webapi/WebIDL/#idl-nullable-type
Received on Monday, 30 November 2009 10:21:37 UTC