Becky wrote:
> Well, I know that people do use find a lot and are frequently tripped up by
> it.
> They get confused over the fact that the fields array is the list of
> fields that are returned AND are searched.
> Most people expect all of the contact information returned and they think that
> the fields are just the fields that will be searched.
That's good feedback, I can't find such feedback in the mailing list archives
[1], although it's possible I brought it up in the evolution from the Contacts
API [2] to the Pick-Contact API [3]. Since there's some renewed interest in the
older spec, it'd be helpful if you'd write a to public-device-a...@w3.org
noting this problem.
Note that current spec [3] doesn't seem to have this problem:
[[[
fields of type array of DOMString
An array of field names corresponding to the name of the fields in the
Contact dictionary that the Web application is requesting from the contact
service. The contact service must not return defined fields on the contact
objects that it provides other than those present in this list. If a field name
is provided that the contact service does not recognise [sic] as a field of the
Contact dictionary, then it must ignore it.
]]]
These are only for returned.
[[[
search of type DOMString, nullable
A string which provides a hint to the contact service to facilitate
contacts selection by the user. The exact manner in which this hint is
exploited is entirely up to the contact service.
]]]
Here, the search is clearly searching only whichever fields the provider
chooses, there's no reason a provider should or would want to consider fields
while applying its search.
The previous spec [2] did do what you described. I think one of the reasons
that Pick-Content is written as is, was to avoid this problem (and partially to
allow the user to say "yeah, I know it was asking for "David", but the guy's
name in my contacts is actually "Dave").
> We did modify the api a bit to add a * in fields to indicate to return all
> fields.
> However, with the field parameter overloaded it does make the search less
> efficient.
> At any rate, I can certainly post to the Phonegap google group asking
> for feedback on the use of remove and request the use cases.
That'd be great.
> Or, you can join and post directly yourself. It's up to you.
I'm much more willing to post questions where I've already done some work. In
Cordova, I've sent a couple of pull requests (some of which have been accepted,
and I have a few I need to repost -- I've refreshed locally), and I've also
given feedback on contributor guides here and some other process aspects, so
I'm not just a `random` person.
> As I'm not active in the W3C currently, I doubt I could get approval and
> funding
> to attend any F2F :-( FYI - I did work actively on WAI/WCAG and some on
> WAI/PF.
:(
[1]
http://www.w3.org/Search/Mail/Public/search?keywords=contacts&hdr-1-name=subject&hdr-1-query=fields&index-grp=Public_FULL&index-type=t&type-index=public-device-apis
[2] http://www.w3.org/TR/2011/WD-contacts-api-20110616/
[3] http://www.w3.org/TR/2012/WD-contacts-api-20120712/
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this transmission
by unintended recipients is not authorized and may be unlawful.
