RE: [Contacts] Contact format issue

Hi Richard, all,

 

 

________________________________

From: public-device-apis-request@w3.org
[mailto:public-device-apis-request@w3.org] On Behalf Of Rich Tibbett
Sent: Thursday, June 24, 2010 4:18 AM
To: Suresh Chitturi
Cc: public-device-apis@w3.org
Subject: Re: [Contacts] Contact format issue

 

On Thu, Jun 24, 2010 at 10:07 AM, Rich Tibbett <rich.tibbett@gmail.com>
wrote:

On Wed, Jun 23, 2010 at 4:47 PM, Suresh Chitturi <schitturi@rim.com>
wrote:

Regarding the "heart-beat" publication of Contacts API we discussed the
issue about using PoCo format for contacts API. I would like to see an
explicit note regarding the contact format (i.e. Portable Contacts)
decision that is used in the API. Something like "The use of Portable
Contacts schema as the format for contacts is subject to further
discussions in the group".

 

I've added a note to the spec.

 

SC> Thanks!

 

	I would remove the following sentence in particular:

	"In addition to the properties defined in this interface, a
conforming implementation must supported both the Singular and Plural
OpenSocial fields defined in [POCO-SCHEMA]." 

	 

These fields are defined in the Portable Contacts specification and are
therefore important for a conforming implementation to implement. We
should not fragment Portable Contacts or the contacts format space any
further by omitting a (large) part of a referenced contact properties
set. If these should not be included, then this should be taken up with
the Portable Contacts group and changed in their specification, which
will filter down to the W3C Contacts API as required. If you're
implementing the Portable Contacts set it should not be a stretch to
implement these fields also.

 

I've added a note that this needs further explanation in the spec,
especially where searching is concerned.

 

SC> I think you are assuming that PoCo is the industry standard for
contacts going forward, and I'm not sure this should be the case. Of
course, our set of properties being compatible with PoCo is different
point. Please read on below...

 

	For e.g. I don't think attributes such as "connected",
"relationships", "published" are within what we call the "minimum" set
supported by implementations.

	 

I've added notes against 'connected' and this note can be applied to all
attributes if desired. We are moving away from a 'minimum' set supported
by implementations due to the fragmentation issues that this introduced.
I've gone in to implementation strategies for such an API [1] [2] though
I hoped that the benefits of a consistent and extensive
ContactProperties set would be self-explanatory for developers, users
and ultimately the non-fragmentation of the web platform.

 

SC> These attributes such as  "connected", 'relationships", "published"
are tied to social networking features and typically not part of the
core contact information set and can easily result in interop issues. I
would like to add a note to all these ones I have raised as an issue
here. I think the other attributes are fine as I believe they are well
within the common set supported today. 

 

Also I am not clear on the semantics of "updated" field and it is tied
to the value of "published".

	Further making it a 1:1 mapping, I think implies to say that we
are not compatible with other formats such as vCard, OMA CAB, etc.?

	 

No.

 

Section 7 of the Portable Contacts spec [3] says the following: 

 

"The traditional contact info fields were taken directly from the vCard
spec where possible [RFC2425], though instances of vCard's archaic
spellings were modernized (e.g. addresses instead ofadr). Even with the
spelling updates, the field mappings remain equivalent, which means it
should be easy to convert Portable Contacts data to and from vCard."

 

In OMA CAB [4] it says:

 

"[The OMA CAB] data model should not preclude support for existing or
legacy data formats (e.g. vCard) as a means

to exchange data with users not yet served by CAB. Several forms of data
availability is being called for with data being

shared with other users as well as with data being formatted in a legacy
format and usable in a variety of non-CAB-specific

exchange activities."

 

A bi-directional conversion path exists between Portable Contacts <->
vCard <-> OMA CAB. Our spec is not the place to get in to such a
discussion as long as the ability is there to convert between formats,
in either a lossy or lossless way.

 

SC> The point I'm trying to make here is that we should not side with
one format or the other but to chose the fields that are most commonly
available. The issue I have with portable contacts is I don't see much
industry support for it. I have not seen a single handset implementation
that is complaint with PoCo, and I don't want us to go in a direction
that ties us to portable contacts which may not be the format of the
future and we will run into issues such as keeping compatibility with it
at all times. Whereas there is a lot of interest with vCard and OMA CAB.
Having said this I am not pushing to support them either. But I also
want to emphasize I like the set of attributes specified by PoCo, except
for the few ones that I have listed above. So we could go with the
current set minus the ones I have raised objection on, and make an
informative reference to PoCo. I think this is the best way forward. And
if we wanted to go an extra step we could add mapping tables in the
Appendix to show how our attributes map to PoCo, vCard, and OMA CAB to
indicate that we have done our efforts to be compatible with as many
formats as possible.

 

Hope this clarifies further.

 

Thanks,

 

Richard

 

 

[1]
http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0039.html

 

[2]
http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0097.html

 

[3] http://portablecontacts.net/draft-spec.html#schema

 

[4]
http://www.openmobilealliance.org/Technical/release_program/cab_v1_0.asp
x


---------------------------------------------------------------------
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.