- From: Carr, Wayne <wayne.carr@intel.com>
- Date: Thu, 18 Oct 2012 02:38:32 +0000
- To: Jungkee Song <jungkee.song@samsung.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Formatting problem - I'll try again I think Bryan's use case is compelling. Was dropping this in response to Web Intents dropping the extras field? That was just because the extras can easily be migrated into the data field. This spec isn't using the data field as input so it's easy to use it for describing the request. I think the data passed in should include: --- requiredFields - don't return contact information that doesn't have values for all of these fields (field names come from 5.1.1) and only return the fields listed optionalFields - also return these values for these fields if available, but don't fail if no values (field names come from 5.1.1) - only fields in either requiredFields or optionalFields are returned valueContainsFilter - array or pairs of fields and values where only contacts where those fields contains those values are returned limit - max number of records returned --- The data returned from the contacts service in 5.1.1 are only the fields listed above and only for contact records that match the requirements (required fields and required values). That prevents having to dump lots of contacts back to the client and having search there. So passes only the information that it needs to pass back. And tells the contacts service what data it wants. Example: the client can ask for contacts that contain "Smith" in the name field and that have an email address - only the name and email address are returned. The draft should be clearer that the user is asked if it is OK to return what was found. A Contacts API has to be able to specify what data it is looking for so that it can be given as little as possible (for privacy reasons). > >>-----Original Message----- >>From: Jungkee Song [mailto:jungkee.song@samsung.com] >>Sent: Monday, October 15, 2012 7:16 PM >>To: public-device-apis@w3.org >>Subject: RE: [Pick Contacts Web Intent] Extend CfC for 'remove search' >>to 22 October >> >>-1. >> >>In addition to Sakari's point, without using search and filtering >>options, I could not come up with any way to support the use case [1] >>Bryan provided. I think the use case is compelling. >> >>The CFC for the 'remove search' is until 22nd of October, please share >>your opinion! >> >> >>[1] >>http://lists.w3.org/Archives/Public/public-device-apis/2012Sep/0119.htm >>l >> >> >>Jungkee >> >>> -----Original Message----- >>> From: Poussa, Sakari [mailto:sakari.poussa@intel.com] >>> Sent: Tuesday, October 09, 2012 4:34 PM >>> To: Frederick.Hirsch@nokia.com; public-device-apis@w3.org >>> Subject: Re: [Pick Contacts Web Intent] Extend CfC for 'remove search' >>> to >>> 22 October >>> >>> -1 >>> >>> I think the client needs to have a way to include search filter. IMO, >>> this is very basic feature in contact API. >>> >>> BR; Sakari >>> >>> On 10/1/12 3:00 PM, "Frederick.Hirsch@nokia.com" >>> <Frederick.Hirsch@nokia.com> wrote: >>> >>> >The decision regarding removing search from the Pick Contacts Web >>> >Intent requires more thought and list discussion based on the issues >>> >raised on the list and the call [1]. >>> > >>> >Thus we should extend the CfC deadline to allow this to happen - >>> >thus let's extend the CfC outlined below to 22 October, giving 3 >>> >more weeks for review and list discussion. >>> > >>> >regards, Frederick >>> > >>> >Frederick Hirsch, Nokia >>> >Chair, W3C DAP Working Group >>> > >>> >[1] >>> >http://lists.w3.org/Archives/Public/public-device-apis/2012Sep/att- >>> 0131/mi >>> >nutes-2012-09-26.html#item04 >>> > >>> >For tracker this should complete ACTION-580 >>> > >>> > >>> >On Sep 19, 2012, at 3:30 PM, wrote: >>> > >>> >> On today's DAP teleconference [1] we discussed removing search >>> >>from the Pick Contacts Intent draft [2]. Our discussion included a >>> >>number of reasons, including the fact that service providers may be >>> >>better positioned to offer integration of search with a meaningful >>> >>and familiar user interface, that matching depends on semantics >>> >>that may not be immediately obvious and may be coupled to the >>> >>service, and a general desire to simplify the specification. >>> >> >>> >> Specifically this would mean removing the ContactIntentExtras >>> >>dictionary definition (4.1.1) and its use case (and would also >>> >>require an update to Example 1). >>> >> >>> >> This is a Call for Consensus (CfC) to remove this search >>> >>functionality from the Pick Contacts Intent draft. Support with a >>> >>+1 to the list is preferred, silence will be considered agreement, >>> >>concern should be expressed to the list. Please respond by 25 Sept 2012. >>> >> >>> >> Thanks >>> >> >>> >> regards, Frederick >>> >> >>> >> Frederick Hirsch, Nokia >>> >> Chair, W3C DAP Working Group >>> >> >>> >> [1] >>> >>http://lists.w3.org/Archives/Public/public-device-apis/2012Sep/att- >>> 0096/m >>> >>inutes-2012-09-19.html#item03 >>> >> >>> >> [2] updated editors draft, >>> >>http://dvcs.w3.org/hg/dap/raw-file/tip/contacts/Overview.html >>> >> >>> >> For tracker this completes ACTION-576 >>> >> >>> > >>> > >> >>
Received on Thursday, 18 October 2012 02:39:08 UTC