- From: Wojciech Masłowski <wmaslowski@opera.com>
- Date: Wed, 16 Jun 2010 11:58:08 +0200
- To: public-device-apis@w3.org
- Message-ID: <4C18A030.6030102@opera.com>
W dniu 2010-06-10 12:31, Rich Tibbett pisze:
> 2010/6/8 Wojciech Masłowski <wmaslowski@opera.comn>
>
>
> Contact interface seems quite minimalistic and doesn't specify any
> extension mechanism. There are many useful contact properties
> which aren't included in the spec like birthday, website etc. I
> understand that the reason for that is mostly because different
> addressbook implementations have different property sets and we
> want to specify only minimal set which will be supported by all
> implementations. The problem is that the proposed property set is
> still extensive enough to be unsupported on some platforms. For
> example oldest SIM cards supported only name and and phone number
> or Windows Mobile(Pocket Outlook) supports only 3 email
> addresses(in dap contacts API there can be arbitrary number of
> emails). Contacts API doesn't specify what to do in those cases ie
> what to do if the field is not supported by the service provider.
> Should saving the contact fail of should it succeed silently
> ignoring unsupported properties. I think this should be specified
> and possibly a mechanism should be added to detect which fields
> are supported.
>
>
> We have discussed the fact that if fields are not supported across all
> implementations they quickly become redundant. On the one hand we have
> a situation where some platforms don't support even the minimal set of
> properties already included in the spec and in other situations we
> don't have enough properties. If I'm not mistaken that makes it pretty
> difficult to produce a reasonable normalized set.
>
> You mention that perhaps a mechanism to detect fields in an
> implementation could be a solution. In practice that would:
>
> - double the coding required from web app developers (API + field
> checking code now required).
> - require that the result of any field detection method also mean that
> the field is ACTUALLY available (rather than saying it is and finding
> out during a save() that it is actually not available for the selected
> data store)
> - require a web app to check for support for every field before usage.
> - require a web app to drop user data in the case that a field is not
> supported in a given store.
> - require a web app to know, ahead of time, which store the user will
> be saving their data to in order too provide the necessary field
> checks. E.g. Perhaps choosing a suitable store may become a part of an
> implementation's 'save process notification' that the user may be
> required to complete.
> - inevitably lead to a user losing data when importing to and
> exporting from different stores.
>
I am aware that complicating the api generally means increasing the bulk
of application code. In this case however This might not be the case.
The problem with unsupported fields arises only when we are trying to
save the data to the addressbook. In practice I see 2 common use cases
for it.
1) A web application which adds some data to contacts( example: a
"add me to your contacts" button on a community portal). In this case
all checking for supported fields can be skipped, because even if field
is not supported it will just not be saved, which is fine in this case -
if your address book doesn't support that field then its fine for UI to
ignore it altogether.
2) Contact management application (example address book manager
widget). In this case field detection method is useful because it would
be really confusing for both developer and user if he tried to write a X
field and after reading it is still not set. In this case field
detection api would allow to hide/disable form field for field X or
handle it in other ways. Without detection mechanism writing such an app
well becomes hard
> I'd like to avoid any and all of these circumstances from occurring.
>
> I briefly mentioned an implementation strategy that was intended to
> normalize all of these issues in [1]: that an implementation is
> capable, and should be responsible, for filling the gap between the
> properties supported in it's available stores and a full contact set
> mandated from a conformant Contacts API implementation. I included a
> couple of real-world examples that I hoped illustrated this could be
> considered as a practical proposal.
>
> How much of that proposal is included in the Contacts API spec, or
> actually needs to be included in the spec, we shall see. I'm currently
> working on creating a full Portable Contacts compliant set of contact
> properties that will be included shortly. By saying that a conformant
> implementation must support the full contact set provided, an
> implementation designer should be capable of designing their
> implementation to work with multiple stores while still being
> compliant to a full properties set at the API level.
>
I've read your proposal about keeping a soft copy of contacts and while
it solves some problems it introduces other. Firstly this will expose a
different set of fields in the UA then in the device's address book
application. Apart from that many address book implementations use some
kind of synchronization mechanisms for devices. Only UA knows about the
soft copied fields so these will not be synchronized. Even if UA
implements a way to synchronize this data between the devices it is not
reasonable to expect for different UA's to be able synchronize data with
each other without specifying explicit protocol for it and I think that
goes beyond the scope of this group's interest. These are subtle issues
but they might cause confusion. All that said I don't say that I am
against it, I just have some doubts about it. Regardless of the way it
is solved however I think clear way of solving issues regarding
different supported field sets needs to be specified both for web
developers and UA implementers.
>
>
> About find I'm wondering if 'multiple' and 'limit' options aren't
> redundant? Isn't limit = 1 equivalent of multiple = false, or am
> I missing something? Apart from that there is no specification
> which contacts are selected when there are more search results
> then limit, but I see a work in progress section for it.
>
>
>
> I see your point that limit=1 is equivalent to multiple=false but I do
> not think this duplication in functionality needs to be an issue. We
> could make the multiple attribute to be interger-based, therefore
> implicitly representing the limit attribute in the multiple attribute.
> What do you think?
>
I think that would work fine.
> Regarding more results selected than limit, I'd expect the limit
> parameter to be enforced by the implementation in their contact picker
> (don't allow more object selections than limit).That may be an issue
> for a UA with a 'pre-defined trust relationship' with a user where no
> user interaction is implied. In that case currently the result will be
> limited to the limit value and there is potential that matching
> results will not make the resulting return if number of results is
> greater than the current limit value. Any proposals to counter this? I
> would say that in cases where no user interaction is provided, the
> 'upper cardinality limit' would likely be very high and the pending
> 'Search Sorting' section should provide guidelines to handle this case.
>
I just think the sorting rules should be defined either as pre-defined
field weights or by adding an option to search that would allow to
specify sorting criteria.
>
>
> I'm also surprised that search mechanism doesn't provide a way of
> filtering using only specified properties and always searches them
> all. Besides that it may be inefficient to search all fields when
> what we are really interested is name(most common use case in my
> opinion), I see use cases of wanting to search only for specific
> fields. For example site would search for contacts whose birthday
> is today and notify you about it(ok I know b-day is not in the
> spec right now, but still I think it is a valid use case for it).
> Another use case could be an application which searches only for
> categories ie. If I search for people in the "work" category I
> wouldn't want Allan Worker from outside of this category to be
> found as well. Or for the matter of fact searching for Michael
> Link would also return all the contacts which have linkedin in
> serviceId.
>
>
> This is a new addition to the specification and is included to
> simplify the search filtering and also to suit the implied user
> interaction of the API as it currently stands. In previous versions of
> the spec, the filter parameter was of type ContactProperties. From my
> work, while this allowed more granular matching to individual fields,
> the filtering applied was difficult and confusing to represent in any
> resulting interface displayed to the user to allow them to select
> contact objects to share.
>
I certainly see usefulness of this mechanism but searching for specific
fields has it's uses also. Searching for specific fields vs searching
over all fields don't necessarily exclude each other.
> Instead I propose a series of search weights to be applied to
> different fields much like a number of search algorithms (e.g. Lucene)
> weight search results according to their relevance. The 'name'
> property would be more weighted than e.g. 'serviceId' properties. So
> in your example (searching for Michael Link), the Michael Link record
> would pop up top of the search list. Any 'linkedin.com
> <http://linkedin.com>' matches on the serviceId would also be matched
> but, with a lower weighting, they would appear as the last objects in
> the resulting success callback.
>
I understand that search weights could be specified by by the
application? If yes then I really like it - it has usefulness and ease
of use of searching all field and possibility of searching specific
fields (by attaching weight = 0 for unwanted fields).
> The implication is that the user can select only the items to return.
> Subsequently, the web app knows where and how the search filter mapped
> to ContactProperties so if you search for a specific birthday and some
> results are returned, the web app is capable of going through the
> resulting objects and saying 'if the match occurs on the birthday
> property then use this record, otherwise ignore this result'.
> Essentially, the search filter is entirely what it says: an intial
> filter to aid the selection of the correct records, whether that be by
> the user and/or the web app as a result of the resulting success callback.
>
Hmm I'd rather like filter being something that can be also used to
specify exactly what you want - that would reduce the amount of code
needed(no need to check on which fields the match occurred) and the
number of contacts to choose from the contact picker.
> Thanks,
>
> - Richard
>
> [1]
> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0039.html
>
--
Wojciech Masłowski
Engeneering CORE Wrocław
Opera Software ASA
http://www.opera.com
Received on Wednesday, 16 June 2010 11:32:27 UTC