W3C home > Mailing lists > Public > public-device-apis@w3.org > November 2009

[contacts] Comments on editors draft of Contacts API

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>
Message-ID: <1259576486.3043.1337.camel@localhost>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:02 GMT