W3C home > Mailing lists > Public > public-device-apis@w3.org > January 2010

Re: Past discussions on vCard datamodel for contacts API (ISSUE-71)

From: Thomas Roessler <tlr@w3.org>
Date: Thu, 28 Jan 2010 13:09:52 +0100
Cc: Thomas Roessler <tlr@w3.org>, <dom@w3.org>, <public-device-apis@w3.org>
Message-Id: <0BB6E675-059F-4497-81B5-55648A1F9372@w3.org>
To: <richard.tibbett@orange-ftgroup.com>
On 28 Jan 2010, at 12:56, <richard.tibbett@orange-ftgroup.com> wrote:

> We initially started with a full mapping to vCard attributes in the
> Contacts API. We have done this exercise previously in this group. The
> historical (read: out-of-date) editor's draft that provides such a full
> vCard mapping can be found here [1].

... and my apologies for not having objected then.  That looks like (much of) it was durint a week that I took off after too much travel.

> 2. Support the smallest possible set of Contact attributes now and allow
> extension attributes to be created by implementations that can be
> proposed to the W3C DAP group (following e.g. wide spread adoption) for
> inclusion in future Address Book APIs. This means allowing the market to
> lead on this stuff without being overly presciptive in the first
> instance. The Contact attributes that have been included to date follow
> an intersection exercise around the Address Book attributes of existing
> implementations which denotes that they are widely supported [3].
> 
> 3. Contact attributes quickly become useless for cross-platform,
> cross-service usage if they are not widely (i.e. always) supported in
> all implementations. We don't want to introduce optionality in to the
> Contact attributes at an early stage but will adopt attributes on an
> ongoing basis. 
> 
> 4. There are incompatibilities between vCard, Portable Contacts,
> OpenSocial and other Address Book services (e.g. OMA CAB [4]) [5] - so
> if we choose one that could come at the detriment of others. Supporting
> a subset of commen attributes as we do now doesn't introduce
> fragmentation, albeit at te cost of limited functionality until we can
> settle on a rich, practical, interop set of attributes to include.

That's (partially) flawed logic:  By introducing yet another subset, we increase the likelihood that future extensions will be done in an incompatible way.  That's something I'd really want to avoid.  I think that, early in the process, we should start out with the full set of attributes from vCard, and only make support for attributes optional if we can't otherwise get through CR.  Note, in particular, that we'd still have to pin down the data model for these attributes in a way that's compatible with the relevant IETF spec.

> The same discussion applies to Calendar Event attributes included.

indeed.
Received on Thursday, 28 January 2010 12:09:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:05 GMT