RE: Contacts API: vCard vs. PoCo

On Wed, 11th Nov 2009 at 04:37, Andrew McMillan wrote: 
> 
> On Tue, 2009-11-10 at 15:19 -0500, Suresh Chitturi wrote: 
> > 
> > Another option would be to consider an API design that will allow 
> > access to a basic set of attributes and would also allow "extended" 
> > attributes that can be supported beyond what is mandated by 
> the spec.
> 
> If the API includes an allowance for storage of arbitrary 
> attributes (possibly arriving in data from external sources) 
> it will need to allow for methods of retrieving all such 
> arbitrary attributes by programs that do not understand their 
> names and meanings so that applications can reassemble the 
> original content without knowing what attributes that 
> original content might have contained.
> 

My understanding, considering the 3 options presented at the F2F (a
superset, a subset or no set attributes for the Contact interface [1]),
is that it is better to have a large set of well-defined attributes
rather than a small set of attributes with developers/implementations
choosing their own fragmented naming for what are effectively the same
attributes. Even if we went with a subset of Contact details, the
problem will be choosing that subset of attributes to define i.e. what
do we put in or keep out? I don't particularly want to go down that
route.

A superset of attributes does not require every implementation to
support all fields. Only a formatted contact name is mandatory in any
Contact object. Everything else is optional at this point. So a vCard
coomplete address book will work equally as well as a partially complete
vCard implementation. Alternatively, with Portable Contacts as the basis
of the Contacts API, a PoCo based address book will work equally as well
as a vCard address book.

So I'd prefer to stick with a well-defined and extensive set of
attributes. That's not to say that developers cannot extend the
attributes...we can define that in the spec. Portable Contacts provides
a more extensive set of attributes than vCard (i.e. additional
OpenSocial attributes) while still supporting vCard interop much like
the current proposal. So rather than developers/implementations adding
inconsistent naming, we end up with a consistent set of fields that will
be used or not used across all implementations.

Kind Regards,

Richard

Received on Wednesday, 11 November 2009 15:59:02 UTC