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

>-----Original Message-----
>From: Tantek Çelik [mailto:tantek@cs.stanford.edu]
>Sent: Wednesday, April 10, 2013 6:25 AM
>To: Suresh Chitturi
>Cc: EDUARDO FULLEA CARRERA; dev-webapi@lists.mozilla.org; JOSE MANUEL
>CANTERA FONSECA; public-sysapps@w3.org; Gregor Wagner
>Subject: Re: [ContactsAPI][DAP-Contacts][divergence] Re: Contacts API and

[...]
>
>Hi Suresh,
>
>Where did those "long discussions" take place? AFAIK they didn't take place
>on the VCARDDAV list.

They took place in DAP.

>
>> and choosing a 'minimum' subset across various contact data models.
>
>Could you please provide URLs to documentation of the research that was
>used to choose the 'minimum' subset? (which specific "various contact data
>models" for example).

Here are some links:
DAP WiKi:
http://www.w3.org/2009/dap/wiki/ContactFormatsComparison

Analysis/Proposal to DAP:
http://lists.w3.org/Archives/Public/public-device-apis/2010Oct/0003.html
https://docs.google.com/spreadsheet/ccc?key=0AlxhCK-xUsPNdDRGSnFZTTAwU3RVdzhVZ1dOaUxCaVE&authkey=CMzj_YcH&hl=en&authkey=CMzj_YcH#gid=0

>
>> The main concern with contact formats is that there is a whole array
>> of formats implemented in the market
>
>In my experience the vast majority of implementations are currently up to
>some subset of vCard3. Some have begun to implement portions of vCard4.
>
>On the web, there is more hCard than all other contact formats put together
>(billions of hCards as of 2011) which is also vCard3 compatible.

Could you provide your findings on concrete vCard3/4 implementations? Almost all the platforms/devices I have seen define their own contact formats.
To make it worse, all the social networks e.g. FB, etc. now have a notion of profile that is more or less contact information. In summary the fragmentation is very high for contact formats (which is unfortunate but a reality).

>
>How recent is your data on these formats, and do you have URLs to
>documentation of the "whole array"?
>
>
>> 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.
>
>If there's an effort to subset vCard, that would be best pursued on the
>VCARDDAV list where a much wider array of folks involved with evolving
>contact standards can bring together a broader set of experiences towards a
>more well informed solution.

The goal was not to subset vCard but to find a 'minimum' set of properties that can be implemented (or mapped) across multiple platforms/implementations including vCard-based implementations.

>
[...]
>
>I tend to agree with the principles of minimization / simplification and thus the
>subset of vCard3/vCard4 in the ContactsAPI is based upon actual address book
>user interface needs.

This is good i.e. if the API is compatible with vCard3/4, but I don't think we should make a broad normative statement that the API is strictly based on vCard 3/4 only.
However, it is very useful for the spec to provide an informative table describing how the API data model maps to various formats e.g. vCard3/4, DAP, OMA CAB, PoCo, etc.
Basically, the summary is that we should define a minimum subset that is compatible with vCard as well as (or as many) other formats as possible. This ensures we have the maximum reach for the APIs!

>
>
>> and extensibility is key.
>
>On this I strongly disagree. Extensibility is the fastest way to encourage
>divergence.
>
>Extensibility is not the key, extensibility is to be avoided in general as it is an
>anathema to standardization and interoperability.
>
>The only exceptions to that are for vendor specific extensions which have no
>intention of standardization (which should also be avoided if possible), and
>experimentation. Both of which are nice-to-haves but certainly not "key".

Not sure if I entirely agree with you here. 
The API should not preclude extensions because 1) The standards process is slow 2) Developers/vendors can use the extensions in the interim until the next update cycle.
This is a pretty common approach in most implementations/open source projects.

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 Wednesday, 10 April 2013 22:46:17 UTC