- From: Carr, Wayne <wayne.carr@intel.com>
- Date: Fri, 19 Oct 2012 02:44:16 +0000
- To: Jungkee Song <jungkee.song@samsung.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
> These seem to be some sort of powerful searching and filtering capabilities on contact database. However, as this is an Web Intents based API, we leave those complex searching and filtering capabilities to service end. You already had it so it only returned fields that were specified as input. So the only difference I suggested there was to mark some as mandatory so if not in the contact record, you don't want that record (like the client app really needs the email address). The search field being undefined seemed fairly useless. It breaks the model of not knowing who provides the service because you have to know the special hints some particular service understands. The filter I suggests enables the use case Bryan suggested where the page that makes the web intents request knows something about the record it wants - like the user has already told it the name. without any filtering the requesting page couldn't pass on the information it knows. And the user has to repeat a step they already did. >-----Original Message----- >From: Jungkee Song [mailto:jungkee.song@samsung.com] >Sent: Wednesday, October 17, 2012 11:09 PM >To: Carr, Wayne; public-device-apis@w3.org >Subject: RE: [Pick Contacts Web Intent] Extend CfC for 'remove search' to 22 >October - formatting problem - resending > >> -----Original Message----- >> From: Carr, Wayne [mailto:wayne.carr@intel.com] >> Sent: Thursday, October 18, 2012 11:39 AM >> >> 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. > >This CFC, discussing on removing search (dictionary ContactIntentExtras) from >Pick Contacts Intent (PCI), does not have to do with getting rid of the "extras" >field [1] of IntentParameters in Web Intents (WI). "extras" in WI was originally >defined to specify extra meta information (url, filename, etc.) about the payload >of "data" field. And as the TF determined to move those extra info into "data" >field, it became useless somehow. On the other hand, we need a field to deliver >optional parameters and used extra of WI for that purpose. Now, I think we can >make use of "data" field of WI in that purpose if we make a decision to retain this >search option capability after all. But I will double check with TF members >whether we better define independent parameters rather than using "data", >though. > > >> 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 > >These seem to be some sort of powerful searching and filtering capabilities on >contact database. However, as this is an Web Intents based API, we leave those >complex searching and filtering capabilities to service end. Service providers can >implement better UX with greater flexibility when we do not impose any >constraints. As we've felt in this demo [2]. The reason why we still retain the >search and filter option here is to cover certain compelling use case in that client >would want to pass some search hints from the page context when invoking the >intent. It's apparently an option for those service providers who really intend to >provide such a customized UX. > > >> --- >> >> 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. > >Again, we expect service providers would provide some sort of strong search UX >and users would exploit "Pick" action from Pick Contacts Intent. ;) > >> 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). > >It can be achieved by "ContactIntentExtras.fields" if we retain the search option. > > >[1] http://lists.w3.org/Archives/Public/public-web-intents/2012Sep/0008.html >[2] http://berjon.com/contacts-intent/ > > > >> > >> >>-----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/at >> >>> >t- >> >>> 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/a >> >>> >>tt- >> >>> 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 Friday, 19 October 2012 02:44:47 UTC