- From: <Cathy.Chan@nokia.com>
- Date: Fri, 20 May 2011 20:02:12 +0000
- To: <public-device-apis@w3.org>
Hi all, I have a few comments on the latest draft of the Contacts API (http://dev.w3.org/2009/dap/contacts/). 1. [small nit] In the example following the Introduction, the Contacts find method was invoked with ['name', 'email'], but the success callback accesses 'displayName', which should not be present in the resulting Contact object. It would be more appropriate and less confusing to use name (or name.formatted) in the success callback instead. 2. [small nit] In 4.3 Contacts Interface (http://dev.w3.org/2009/dap/contacts/#contactname-interface), the note "Each Contact must include either a displayName or the name attribute." which appears under the description of displayName should appear under the description of the name attribute as well. 3. [question] 5.1 Search Qualifiers (http://dev.w3.org/2009/dap/contacts/#search-qualifiers) says "If the search qualifier provided is of zero-length then the current Contacts find() operation must not return any Contact properties within any resulting Contact object(s)." Does that mean the success callback would be invoked with one or more Contact objects each with no properties at all? Wouldn't that contradict with the statement that "Each Contact must include either a displayName or the name attribute."? 4. [bug] In 4.8 ContactFindOptions interface (http://dev.w3.org/2009/dap/contacts/#contactfindoptions-interface), the description of the 'multiple' attribute says "By default this option is set to true." But in 5.2 Options Processing (http://dev.w3.org/2009/dap/contacts/#options-processing), it says that "By default, the Contacts find() operation must return either an empty sequence or a single Contact object, accessible as part of the sequence returned in the ContactFindCB callback function", and that the 'multiple' attribute needs to be set to true to retrieve multiple objects. To me, that reads "the attribute is false by default". Which one is correct? Regards, Cathy.
Received on Friday, 20 May 2011 20:02:42 UTC