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


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