RE: [contacts] Comments on editors draft of Contacts API

On 30th Nov 2009, at 17:34, Robin Berjon wrote:
> 
> Can you give us a quick rundown of what the interoperable 
> subset that you have is? Does it match your API? If so I'm in 
> favour of drastically reducing the surface of our current 
> draft (we were looking for reasons to do that at the f2f but 
> alas lacked input).
> 

Any subsetting must, at the very least for v1, also support other
existing implementations (i.e. Nokia and BONDI implementations)...but I
want to clarify this point in light of PhoneGap's proposal:

Any and all attributes provided in ContactProperties are independently
optional (other than name.formatted). If an implementation does not
support any particular attribute, it simply does not need to exist in
the implemented Contact interface. This fits with the subset that
PhoneGap proposes to implement (as was entirely expected).

There are words to this effect in the Contact interface [1] (para 2),
though I propose the following addition to the Contacts API
'Introduction' for clarification:

'... This specification does not require any implementations to support
the vCard standard, in part or in its entirety, at any time. vCard
properties and values are informatively referenced in this specification
as a guideline to providing effective and consistent naming of address
book attributes across implementations. 

An implementation is also not required to support the full set of
ContactProperties defined in this specification. An implementation MAY
support either a full set or a subset of the defined ContactProperties
depending on the attributes supported by the implementation or its
associated platform(s). The name.formatted attribute MUST be supported
in all implementations. All other attributes are OPTIONAL.'

So at present we have a superset of contact attributes. A set of
well-defined property names for more attribute-complete implementations
or for potential future extension by existing subsetted implementations
(e.g. PhoneGap).

While some implementations will support e.g. 3 attributes, others may
support e.g. 6 or 10. The superset of ContactProperties specified is the
full set but is primarily intended for subsetting and for subsetted
implementations to expand in to a well-defined attribute naming space as
or when required in the future. Rather than individual implementations
introducing different naming and structures for what are effectively the
same object strucures at some point in their evolution, the current
proposal defines naming that they can all grow in to in a consistent way
up front (obviously, up to a certain point).

Kind Regards,

Richard

[1] http://dev.w3.org/2009/dap/contacts/#contact-interface

Received on Tuesday, 1 December 2009 12:04:32 UTC