[Contacts] DVCS move and other updates

So, darobin and dom have moved the contacts spec into hg: http://dvcs.w3.org/hg/dap/rev/ce922ee80ed2


I wrote a draft change to address the i18n feedback point about ContactName (which is basically axing it):

https://bitbucket.org/timeless/dap/changeset/d24c7fa073a4


in the process, I've run across a number of issues with the spec:
1. the spec was alerting non string objects in its tests, this will not do something useful. We probably need to have a wiki point to warn people about this.
Since the thing it was alert()ing went away, I decided that instead of changing all of the alerts from alert(foo.name) to alert(foo.displayName) that it would be simpler to just rename displayName to name. If someone ever feels some *great* need to bring back a ContactName object, they can use some longer field name (or 'n' if they insist on shorter names). Because of the rename, you won't see that the alert()s were bad.

-- renaming displayName to name will of course affect existing implementations. Otoh, so would just dropping name. And if anyone actually did try to alert(...name) they'd get better results.... Either way, dropping the ContactName changes/breaks the interface, and was a necessary step.

2. the spec tries to address a privacy concern by offering an ldap oriented subselect for the fields that an app is asking of a user. This is the classic java approach to security: let an app ask for an incredibly large list of fields. The result is an overwhelmed user who gives up and says "whatever". [If "ldap oriented subselect" confuses you, imagine how a user would feel.]

A basic fix for this it to get rid of most of the sub selectable fields entirely (I'll draft a change for this next week, I ran out of time this week), but basically what I did for ContactName (axing it) will apply to Address. Conveniently, getting rid of the sub fields in Address will resolve our conflict issue with the GeoLocation group.

3. the spec has some confusing verbage involving 'fields' and filters. It really confused both myself and my predecessor, Suresh (who had previously worked on this spec). I'm going to also propose a change which tries to improve the descriptions (and probably will rename some of the parameters). It shouldn't actually affect existing implementations since it doesn't affect how one calls the functions, but it will make things clearer to consumers reading the API.

Anyway, that's my rough todo list (oh, and I'll be marking myself as a coeditor too...).

---------------------------------------------------------------------
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 Friday, 21 October 2011 19:49:20 UTC