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

Received on Thursday, 28 January 2010 11:57:47 UTC