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

On Tue, Apr 9, 2013 at 12:52 PM, Suresh Chitturi
<schitturi@blackberry.com> wrote:
> 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

Hi Suresh,

Where did those "long discussions" take place? AFAIK they didn't take
place on the VCARDDAV list.


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


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

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.


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

I agree that when there is commonality/overlap it is best to seek convergence.

On the subject of contacts data models, that convergence has
historically occurred across numerous standards and groups on the
VCARDDAV list for many years now and should continue there.

https://wiki.mozilla.org/ContactsAPI#How_do_we_best_converge_contact_data_models


> given both groups are in W3C and it is bit odd to see different data models for the same functionality.

Anyone is able to join the VCARDDAV list.

There's no reason for W3C groups to attempt to converge apart from the
existing convergence in VCARDDAV.

Converging apart from existing convergence is in fact be a form of
divergence and should be discouraged.


> Generally what we have found is that the less attributes normatively specified in the data model the better for compatibility across multiple platforms,

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.


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

Thanks,

Tantek

Received on Wednesday, 10 April 2013 11:26:22 UTC