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,

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

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

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


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

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

> 3)      Address the mapping of these fields to other known formats
> 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.

- Rich

Received on Tuesday, 28 September 2010 23:31:31 UTC