- From: Rich Tibbett <richt@opera.com>
- Date: Thu, 09 Sep 2010 10:45:31 +0200
- To: Renato Iannella <renato@iannella.it>
- CC: public-device-apis@w3.org
Renato Iannella wrote: > > I am actually quite surprised that Portable Contacts is what the > Contacts API WD is based on. > > All of the attributes listed in that Working Draft are pretty much what > is in vCard (the industry standard with the widest deployment, from the > IETF). I did not see the xtra social attributes listed (eg food, heroes, > etc) used by PoCo. > > I tried to look thru the email archives to see why....and found a small > discussion [1] with the argument: > > "As PoCo represents a larger set of Contact attributes, I'd like to > propose that we make PoCo the basis of the DAP Contacts API" Firstly I will say that nothing is set in stone here. There's a note in the spec specifically pointing to the fact that formats are currently under discussion. The spec is at the Working Draft stage specifically for this reason (and why we're not publishing it tomorrow). It has hardly been a trivial discussion over the past few months and there are a _lot_ of discussions on the contacts format that we should use on the mailing list. A number of web services use Portable Contacts and OpenSocial as the basis of Contact Information Sharing. Traditional Address Books, for the most part, use vCard. The Contacts API acts in the space between the device and the web and so choosing a device facing or web facing paradigm is going to result in someone losing data in transfer somewhere. Someone is going to be unhappy and so if we displease everybody equally but arrive at a workable solution, without re-inventing the formats, then perhaps we could live with that. On top of that, the vCard standard does not provide a JSON mapping for its properties at present. It doesn't translate well to communication over the web at large. The DAP WG is defining WebIDL based APIs with the objective of being able to apply these definitions to REST-based API interactions in the future. Finally, we have also specified the format based on real-world implementations around this concept, most notably the Mozilla Contacts project [3]. > > Again, this "larger set" is not evident in the WD. We're still deciding how to cover the larger set hence why we are still at the Working Draft stage. My current plan was to stick with the basic Portable Contacts set included in the spec and then provide clear extension guidelines for developers to provide the larger set of OpenSocial properties as required. > > Was this the right decision to make? Given the provenance and industry > acceptance of vCard? Frankly we're between a rock and a hard place on this created by the incompatibility between Portable Contacts and vCard. The right decision is the wrong decision for someone else? Why is that? Why, in 2010, can we not agree on a single format to rule them all? Why am I losing my hair? Portable Contacts aims to cover the fields of vCard (except for using e.g. archaic spellings) which provides a route to generating vCard data from an object provided by the API. On top of that the vCard spec also provides good extension guidelines. With the aid of a co-ordinated 'Portable Contacts extensions for vCard' draft, or a company-driven implementation of the same thing, we might be able to make such a solution work and grow at its own pace. > > And, ironically, the Introduction [2] says "The API itself is agnostic > of any underlying address book sources" Right. Apologies if that is not clear. It means that an underlying address book can be in whatever format it likes but when it is served up via the Contacts API it assumes the format described in the spec. It means that data storage is not necessarily equal to the required input/output via the API. - Rich > > Cheers > > Renato Iannella > http://renato.iannella.it > > [1] http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0045.html > [2] http://www.w3.org/TR/2010/WD-contacts-api-20100701/#introduction > [3] http://mozillalabs.com/contacts
Received on Thursday, 9 September 2010 08:46:09 UTC