W3C home > Mailing lists > Public > public-device-apis@w3.org > September 2010

Re: [contacts] Updated draft available

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Wed, 15 Sep 2010 11:04:27 +0200
To: Rich Tibbett <rich.tibbett@gmail.com>
Cc: public-device-apis@w3.org
Message-ID: <1284541467.2387.2115.camel@localhost>
Le lundi 13 septembre 2010 à 16:28 +0200, Rich Tibbett a écrit :
> I've created a new draft of the Contacts API based on feedback
> received to date: http://dev.w3.org/2009/dap/contacts/ (Ctrl+R to
> refresh may be required)
>
> There will still be a number of items that will require further work
> in light of the ongoing discussions related to formats. Your feedback
> on the latest draft would be most appreciated.

I've brought a few editorial changes directly in the document itself,
mostly to take into the account the fact that the spec is now only about
find() (and no longer about save() and remove()).

Some comments from a quick new review:
• why do we have both "limit" and "multiple" in ContactFindOptions?
wouldn't limit=1 be equivalent to multiple=false?

• you imported startDate/endDate for the organization data; while I can
see it being useful in a social network, that seems somewhat of an
overkill for an addressbook; that said, it probably doesn't hurt to have
it included if that facilitates interoperability

• I wonder if xs:dateTime is the best format for the updatedSince option
in ContactFindOptions; shouldn't we using the EcmaScript Date interface
instead?

• rather than “complex”, I would use the word “composed” to qualify
attributes that are not directly accessible

• I don't recall any discussion on the search sorting algorithm; was
this inspired from a similar algorithm somewhere else? I'm not sure the
API should impose anything on sorting, I would prefer leaving this to
external libraries

• requiring (with a MUST) an ill-defined "loose-matching policy" seems a
bit strong; I would turn that into an implementation advice; the MUST
can probably still be applied to the fact that implementations need to
apply the search to all the attributes being retrieved; likewise, I
would demote the normativeness of the compatibility caseless requirement
for partial value match

• the search filter algorithm says on successful match that “that
Contact object must be returned as part of the resulting
ContactFindSuccessCB” — that’s a bit misleading given that the user may
or may not choose to include that contact in the data that is provided
to the application; as far as I can tell, the search filter is more a
hint to allow pre-filtering the list of contacts from which the user
will select what to send to the app; I think this means also more or
less dropping (or turning into purely advisory material) the rules for
processing search filters; 

• I'm not sure to understand why “The id attribute must always be
implicitly searchable”; if it really MUST, it should be included in the
example of fields that needs to be searched just after that sentence

• I think people tend to prefer vendor prefixes to X prefixes for
extensions, as they avoid conflicting extension names; any reason why
you chose "X"?

HTH,

Dom
Received on Wednesday, 15 September 2010 09:04:35 GMT

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