- From: Tantek Çelik <tantek@cs.stanford.edu>
- Date: Mon, 8 Apr 2013 16:44:55 -0700
- To: EDUARDO FULLEA CARRERA <efc@tid.es>
- Cc: "dev-webapi@lists.mozilla.org" <dev-webapi@lists.mozilla.org>, JOSE MANUEL CANTERA FONSECA <jmcf@tid.es>, public-sysapps@w3.org, Gregor Wagner <gwagner@mozilla.com>
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. > [...] > - I would like to know whether you have any preference with regards to those aspects in which W3C DAP's Pick Contact Intent difer from Firefox OS Contact API, The differences you point out all appear to indicate divergences in the design of W3C DAP's Pick Contact Intent: > namely: > -Grouping organization related fields under ContactOrganization dictionary, including additional 'department' field. No addressbook user interfaces UIs make any such distinctions, on the contrary, typical address books UIs have a simple string field like "Company" (iOS, Android). Thus we should avoid introducing any such hierarchy or new interfaces. "department" is not mentioned in vCard. > -Grouping name related fields under ContactName dictionary This also seems like unnecessary hierarchy. > -ContactField includes Boolean pref (as explained above) Including an integer pref for forward compat with vCard4 makes more sense, while we can give it a Boolean semantic in the spec for now. [PREF] thread coming up with details. > -some fields wording (tel, imp, bday, adr, org, jobtitle, country) The Pick Contact API renamed these (diverged) from vCard. This is unfortunately a common anglo-centric renaming/bikeshed error. http://microformats.org/wiki/naming-principles#Anglo_centric_renaming_when_reusing > -is 'additionalName' in FFOS API equivalent to 'middleName' in Pick Contacts? additionalName is reused from the vCard (3&4) description of "Additional Names". 'middleName' in Pick Contacts appears to be unnecessary renaming (divergence) per the same anglo-centric-renaming anti-pattern. Thanks, Tantek
Received on Monday, 8 April 2013 23:46:02 UTC