canmove, Confirmed users
2,675
edits
(→FAQ: How do we best converge contact data models) |
(FAQ: Should the ContactsAPI data model change for DAP Contacts (no), and more details) |
||
Line 259: | Line 259: | ||
One exception is the "carrier" field which has been marked experimental, and which should be proposed to VCARDDAV by someone who can justify it with real world use cases / examples, or dropped from the ContactsAPI. | One exception is the "carrier" field which has been marked experimental, and which should be proposed to VCARDDAV by someone who can justify it with real world use cases / examples, or dropped from the ContactsAPI. | ||
=== Should the ContactsAPI data model change for DAP Contacts === | |||
In short, no, the ContactsAPI should not change for DAP Contacts. | |||
Since the ContactsAPI's data model is already directly based on the core and more popular [[vCard]]/[[hCard]] standards, it should NOT be changed in response to other downstream specifications. | |||
Instead, any other downstream specifications (whether DAP Contacts or others) should be encouraged to converge with the ContactsAPI, or at least with vCard/hCard directly. | |||
=== Why are givenName familyName arrays instead of optional === | === Why are givenName familyName arrays instead of optional === | ||
Line 268: | Line 275: | ||
=== Is the name property a composition or something users enter === | === Is the name property a composition or something users enter === | ||
* Is the name property a composition of given and family name or is it something users can enter? | * Is the name property a composition of given and family name or is it something users can enter? | ||
** '''The name property is 'fn' and can be entered by users.''' The 'name' property is the replacement for 'fn' (formatted name) from vCard/hCard. This is an explicit renaming (to 'name') that multiple parties have independently done (decentralized convergent evolution), and thus is being adopted in [[hCard 2]] and thus we are adopting as well in the ContactsAPI | ** '''The name property is 'fn' and can be entered by users.''' The 'name' property is the replacement for 'fn' (formatted name) from vCard/hCard. This is an explicit renaming (to 'name') that multiple parties have independently done (decentralized convergent evolution, the one exception being DAP which called it 'displayName'), and thus is being adopted in [[hCard 2]] and thus we are adopting as well in the ContactsAPI. | ||
=== Why are abbreviations used for adr bday org tel === | === Why are abbreviations used for adr bday org tel === | ||
Line 313: | Line 320: | ||
=== W3C DAP Contacts === | === W3C DAP Contacts === | ||
The DAP WG (W3C) has a contacts | The DAP WG (W3C) has a contacts API working draft [1] sharing some of the goals of this proposal. | ||
[1] http://www.w3.org/TR/2011/WD-contacts-api-20110616/ | [1] http://www.w3.org/TR/2011/WD-contacts-api-20110616/ | ||
The Contacts API proposal differs from the DAP specification in some key ways: | |||
* The ContactsAPI preserves much better convergence with [[vCard4]]/[[hCard]]. | |||
* The ContactsAPI is a simplified / flattened properties/interfaces/API per lessons learned with the development of both [[vCard4]] and [[hCard]] (including [[hCard 2]]) | * The ContactsAPI is a simplified / flattened properties/interfaces/API per lessons learned with the development of both [[vCard4]] and [[hCard]] (including [[hCard 2]]) | ||
* The ContactsAPI's read/write API is explicitly designed to avoid multi-access write corruption. | * The ContactsAPI's read/write API is explicitly designed to avoid multi-access write corruption. | ||
Both of the above are fairly significant fixes to major problems in the W3C DAP Contacts API. | Both of the above are fairly significant fixes to major problems in the W3C DAP Contacts API. | ||
There's also the W3C's wiki page on [http://www.w3.org/2009/dap/wiki/ContactsMozDapComparison ContactsMozDapComparison] but it is quite out of date. | There's also the W3C's wiki page on [http://www.w3.org/2009/dap/wiki/ContactsMozDapComparison ContactsMozDapComparison] but it is quite out of date. | ||
* '''Update W3C ContactsMozDapComparison page''' with the advantages / reasoning of the ContactsAPI. | |||
== Clients == | == Clients == |