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

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

From: Suresh Chitturi <schitturi@rim.com>
Date: Sun, 31 Jan 2010 03:54:23 -0600
Message-ID: <D37CC1B151BD57489F4F89609F168FE80407FC39@XCH01DFW.rim.net>
To: <tlr@w3.org>
Cc: <richard.tibbett@orange-ftgroup.com>, <dom@w3.org>, <public-device-apis@w3.org>

Providing an informative mapping to vCard properties is fine but using it as a basis for our data model is something I'm not convinced.  

There are several standard (e.g. vCard, XMPP, Portable Contacts, OMA CAB) and proprietry contact formats (e.g. internet-based and handset/device based). In this situation, I don't believe vCard stands out as the preferred format.

Our goal I believe should be to provide access to underlying address books whether it be on the device or a service, but not the other way around i.e. forcing implementations to support a specific model.

The common/minimum subset approach allows compatibility with almost all formats out there, and I believe this is the best approach at least for the first version.  

Regards,
Suresh


----- Original Message -----
From: Thomas Roessler <tlr@w3.org>
To: Suresh Chitturi
Cc: Thomas Roessler <tlr@w3.org>; richard.tibbett@orange-ftgroup.com <richard.tibbett@orange-ftgroup.com>; dom@w3.org <dom@w3.org>; public-device-apis@w3.org <public-device-apis@w3.org>
Sent: Fri Jan 29 07:23:36 2010
Subject: Re: Past discussions on vCard datamodel for contacts API (ISSUE-71)

On 28 Jan 2010, at 23:49, Suresh Chitturi wrote:

> In addition, I would like to state the market is already very much fragmented in this space.

We certainly don't help it by adding further fragmentation.  The current working draft (when looked at from a vcard perspective) does precisely that.  E.g., how is the "premises" attribute mapped into vcard?

> It is only a model that is used to transport contact information and our use case is not really that but to give web apps the data from the "underlying address books".

I disagree with that scope point.  The API we're talking about should: 

- be able to deal with address books that reside on the network; for these, vcard is the standard of record  (feel free to suggest another one)
- be useful as a JSON binding that can be used as a network transport

(There's, in fact, a requirements discussion in here that's perhaps best framed in those very terms.)

One way to achieve that would be to indeed focus on the API framework, and simply define a mechanical mapping from vcard to JavaScript objects.


---------------------------------------------------------------------
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 Sunday, 31 January 2010 10:00:56 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:41 UTC