Re: [Contacts] Contact format issue

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.


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


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


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

Thanks,

Richard