RE: Past discussions on vCard datamodel for contacts API (ISSUE-71)

+1. I concur with all the points below from Richard.

In addition, I would like to state the market is already very much
fragmented in this space. 

For W3C the focus really I think should be to standardize the
"framework" i.e. APIs rather than the underlying data model. So the best
solution for the first version is to support a "common" subset.

Also I don't think vCard is the best model out there besides other
concerns such as IPR, etc. I haven't seen vCard data model implemented
device address books. It is only a model that is used to transport
contact information and our use case is not really that but to give web
apps the data from the "underlying address books".

We did discuss these aspects, before making a resolution, and now going
back to it is counter-productive in my view.

HTH,
Suresh

-----Original Message-----
From: public-device-apis-request@w3.org
[mailto:public-device-apis-request@w3.org] On Behalf Of
richard.tibbett@orange-ftgroup.com
Sent: Thursday, January 28, 2010 5:57 AM
To: dom@w3.org; public-device-apis@w3.org
Subject: RE: Past discussions on vCard datamodel for contacts API
(ISSUE-71)

Hi,

Firstly, apologies that I missed the call yesterday as I had an
ill-timed travel arrangement that cut right through the meeting.

We initially started with a full mapping to vCard attributes in the
Contacts API. We have done this exercise previously in this group. The
historical (read: out-of-date) editor's draft that provides such a full
vCard mapping can be found here [1].

Following the publication of this draft, we adopted a small (sub)set of
Contact attributes around 4 basic principles:

1. Promote what we absolutely need in the first instance. Future
versions can promote what we really think should be in this API on top
of those fundamental attributes and allows us more time to assess
individual attributes on a case-by-case basis [2].

2. Support the smallest possible set of Contact attributes now and allow
extension attributes to be created by implementations that can be
proposed to the W3C DAP group (following e.g. wide spread adoption) for
inclusion in future Address Book APIs. This means allowing the market to
lead on this stuff without being overly presciptive in the first
instance. The Contact attributes that have been included to date follow
an intersection exercise around the Address Book attributes of existing
implementations which denotes that they are widely supported [3].

3. Contact attributes quickly become useless for cross-platform,
cross-service usage if they are not widely (i.e. always) supported in
all implementations. We don't want to introduce optionality in to the
Contact attributes at an early stage but will adopt attributes on an
ongoing basis. 

4. There are incompatibilities between vCard, Portable Contacts,
OpenSocial and other Address Book services (e.g. OMA CAB [4]) [5] - so
if we choose one that could come at the detriment of others. Supporting
a subset of commen attributes as we do now doesn't introduce
fragmentation, albeit at te cost of limited functionality until we can
settle on a rich, practical, interop set of attributes to include.


Perhaps we could come up with a general process for proposing new
attributes that includes a checklist on the practicality of any
particular attribute based on the principles above.

The same discussion applies to Calendar Event attributes included.

Kind Regards,

Richard


[1]
http://dev.w3.org/cvsweb/~checkout~/2009/dap/contacts/Overview.html?rev=
1.14&content-type=text/html;%20charset=iso-8859-1#idl-def-ContactPropert
ies

[2]
http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0251.html

[3]
http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0010.html

[4]
http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0066.html

[5]
http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0047.html



----------
|        |   Rich Tibbett
|        |   Orange Labs UK
| orange |   E: richard.tibbett@orange-ftgroup.com
----------   


> -----Original Message-----
> From: public-device-apis-request@w3.org 
> [mailto:public-device-apis-request@w3.org] On Behalf Of 
> Dominique Hazael-Massieux
> Sent: 27 January 2010 16:11
> To: public-device-apis@w3.org
> Subject: Past discussions on vCard datamodel for contacts API 
> (ISSUE-71)
> 
> Hi,
> 
> During the call today we raised an issue on the difference of 
> data model between the Contacts API and vcard, the Calendar 
> API and vcalendar (ISSUE-71).
> 
> I've documented in Tracker links to the previous discussions 
> we had on this topic for the Contacts API:
>         * IETF and IPR questions
>         
> http://lists.w3.org/Archives/Public/public-device-apis/2009Dec
/0004..html
>         * vCard vs Portable Contacts
>         
> http://lists.w3.org/Archives/Public/public-device-apis/2009Nov
/0045..html
>         * comparison of properties supported across platforms
>         
> http://lists.w3.org/Archives/Public/public-device-apis/2009Dec
/0010..html
>         * decision to trim down Contacts API properties
>         
> http://lists.w3.org/Archives/Public/public-device-apis/2009Dec
/att-0154/02-dap-minutes.html#item03
> http://www.w3.org/2009/dap/track/issues/71
> 
> HTH,
> 
> Dom
> 
> 
> 
> 

*********************************
This message and any attachments (the "message") are confidential and
intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered,
changed or falsified.
If you are not the intended addressee of this message, please cancel it
immediately and inform the sender.
********************************



---------------------------------------------------------------------
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.

Received on Thursday, 28 January 2010 22:50:33 UTC