RE: [ContactsAPI][DAP-Contacts][divergence] Re: Contacts API and W3C SysApps

Hi Tantek, all,

>-----Original Message-----
>From: Tantek Çelik [mailto:tantek@cs.stanford.edu]
>Sent: Monday, April 08, 2013 6:45 PM
>To: EDUARDO FULLEA CARRERA
>Cc: dev-webapi@lists.mozilla.org; JOSE MANUEL CANTERA FONSECA; public-
>sysapps@w3.org; Gregor Wagner
>Subject: [ContactsAPI][DAP-Contacts][divergence] Re: Contacts API and W3C
>SysApps
>
>On Fri, Mar 22, 2013 at 5:41 AM, EDUARDO FULLEA CARRERA <efc@tid.es>
>wrote:
>> [...]
>>
>> The working assumption is to make the contact data model in this API and in
>W3C DAP's Pick Contact Intent [2] converge (TBD which one to be modified).
>
>>From both previous evaluation of the W3C DAP Contacts API and recent
>review (when did the generic w3.org/tr/contacts-api URL morph into an
>"intent" spec and will it morph back?), it appears that the W3C DAP Contacts
>API has diverged in a number of ways from vCard's data model, especially
>given the specifics raised below.
>
>Rather than attempting convergence with an API that itself has diverged from
>vCard, we should instead encourage the DAP Contacts API to first better align
>with vCard's data model and re-use existing points of coordination if DAP
>Contacts API has any disputes with vCard's data model.

Just to give some background, the DAP WG did not diverge from vCard intentionally but a result of long discussions and choosing a 'minimum' subset across various contact data models.
The main concern with contact formats is that there is a whole array of formats implemented in the market and the group did not see a point to force the API to one format or the other, hence the best decision was to define a minimum subset while allow a mechanism for implementations to extend the API to align with the platform implementation(s). Note that DAP carefully chose the semantics of the supported attributes to align with vCard as much as possible. 

This is not to say that Sys Apps should rubber stamp DAP spec but when there is commonality/overlap it is best to find a common solution, given both groups are in W3C and it is bit odd to see different data models for the same functionality. Generally what we have found is that the less attributes normatively specified in the data model the better for compatibility across multiple platforms, and extensibility is key.

Hope this helps.

Regards,
Suresh


---------------------------------------------------------------------
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 Tuesday, 9 April 2013 19:53:30 UTC