RE: ISSUE-98: contactsDataModel (from Suresh)

Hi Richard, all,

Please see below.

-----Original Message-----
From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of Rich Tibbett
Sent: Tuesday, September 28, 2010 6:30 PM
To: public-device-apis@w3.org; Frederick.Hirsch@nokia.com
Subject: Re: ISSUE-98: contactsDataModel (from Suresh)

On Wed, 29 Sep 2010 00:10:53 +0200, Suresh Chitturi wrote:
>
> While reviewing the Contacts API updated draft, my main concern at this  
> point lies with the contact format used by the API. It largely continues  
> to use/refer to the schema from Portable Contacts, but we have seen  
> equal interest to use other formats such as vCard and OMA CAB.

Contrary to some belief the spec is not built solely around Portable  
Contacts. It just happens that the PoCo spec has some pretty neat  
descriptions of the elements that we are using and rather than copy/paste  
we just refer to those descriptions instead. It is not intentionally  
reliant on the PoCo spec. Perhaps we should just describe the elements  
directly in our spec instead,

Suresh>> Thanks for clarifying this. Unfortunately, this is not the case when you read the spec. I would strongly suggest that we re-use the descriptions from PoCo if they are appropriate rather than referencing them. This will ease a lot of things and will not give a wrong message to the audience. I remember you did have the descriptions in the previous versions.

The attributes used in the W3C Contacts API equally belong to the vCard  
standard.

Suresh>> The key is which version of vCard. If you are saying vCard 4.0 I don't think it is good idea which is not frozen and not as commonly used and this is the same case with PoCo and CAB. Therefore, the push for a "minimum" set that can map well to all the candidate formats, and this is the best we can position ourselves at the moment.

> Can we please add this topic to this week’s agenda so we may try to  
> discuss how this can be resolved going forward?
>

Do you have any new proposals for moving this topic forward on the call  
tomorrow? Otherwise, this has been discussed as a general concept to  
death. Let's get to specifics...

Suresh>> trying to with this thread:-)

> Starting with the fields, I am generally happy with the set of contact  
> attributes in the current spec which are compatible with fields in vCard  
> [RFC 2426], and OMA CAB based on my checks

Great! Thanks for cross-checking this.

> , except the following ones:
> -          updated

= vCard 'rev' field (v2.1-v4).

> -          relationships

= vCard 'relation' field (v4 only but quite easily 'x-relation' for vCard  
v2.1-v3).

> -          anniversary (not present in vCard)
>

= vCard 'anniversary' field (v4 only but quite easily 'x-anniversary' for  
vCard v2.1-v3).

Suresh>> Again these are v4 only, and what about CAB? If we start to pick and choose there are a bunch of attributes in CAB and vCard 4 that we need to adopt if we want to get all this right. Moreover, the fields 'updated' (it depends on 'published' btw) and 'relationships' are not core to the address book, but tied to a social service.

> I’d suggest that we address this in multiple steps e.g. as below
>
> 1)      Agree on the set of fields to include

It seems we agree on the general fields pending discussion of the above 3  
fields (updated, relationships and anniversary).

Suresh>> Yes, subject to not reference a particular contact standard.

> 2)      Decide on the structure and semantics of the selected fields

This we must and should continue to work on within the spec and I  
encourage all feedback on this stuff at any time on the mailing list.

Suresh>> I agree, if you could please revise the draft to remove the external schema references I think we can move forward rather very quickly...

> 3)      Address the mapping of these fields to other known formats

Suresh>> For this my suggestion is to do some work in the Annex similar to following exercise: http://spreadsheets.google.com/pub?key=pSGbbhtwI4kN_nJ1GXeQ7Qg


> 4)      Extension mechanisms (which we seem to have in place and it  
> looks fairly ok to me)
>

Please keep it coming if you continue to have concerns. We promise to  
please everybody none of the time...but we're trying hard to be better.

Suresh>> Hope my responses here helped!

- Rich



---------------------------------------------------------------------
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 Wednesday, 29 September 2010 00:28:49 UTC