RE: Schedule and criteria for FPWD of Contacts API

On 1st Dec 2009, at 19:10, Suresh Chitturi wrote:
> One of my key concerns of the current draft is the scope 
> (that was raised by a few others on the list) and the so 
> called 1:1 alignment with vCard. If we really want to proceed 
> with FPWD soon, I'd rather go with a very simple, and a small 
> set of functionality that we know is supported by devices 
> today which is actually quite close to the functionality 
> present in the inputs submitted to the group and are posted 
> on our charter page.

I agree and I'm now on board with this
intersection(current_implementations) concept.

While there may have been *some* value in expanding quickly in to a
well-defined attribute naming area, I completely agree with the point
that unsupported attributes will be ignored by devs and become, to all
intents and purposes, irrelevant in the short/medium term. 

As and when we can expand a smaller set makes more sense, as long as any
version 2 updates are timely and implementations don't splinter around
different names for the same extended attributes in the interim.

> Regarding vCard, I am personally not against the content of 
> vCard spec but saying that our spec is a 1:1 mapping is 
> mis-leading. vCard was designed as a format for transporting 
> contact information and our focus is accessing the device 
> functionality i.e. functionality supported natively by the 
> device. Of course we can use vCard as the basis (e.g.
> use the semantics of contact properties, etc) but designing 
> our API with strict alignment with vCard is too strong a 
> requirement.

We are using the semantics only. If someone else had given me a
comprehensive list of well-defined contact attributes then that would
have been used. It just happens that the vCard specification includes
such a well-defined list of attributes so we went with that in the first

Perhaps it should read as a 1:1 representation rather than mapping.
Either way, if this stands, it needs to be further clarified in the

> I can understand the superset argument, but if 
> devices end-up not supporting all the vCard attributes 
> natively (which is the case today), and we restrict the 
> mandatory attributes to only a few don't see much value in 
> terms of application/content re-use. Ideally, we should 
> expect that all the attributes we define are mandatory and 
> this can only happen if we had a small set of key attributes.

I now agree.

> Another observation from the current draft is that we have 
> way too many interfaces defined - this is not optimal for 
> mobile. This is probably one of the side effects of strict 
> mapping to vCard. We can surely optimize this (e.g. collapse 
> some interfaces) with some analysis. 

Yes we can. Currently the spec is narrow and deep. That depth will be
trimmed with the removal of a number of contact attributes that cannot
be supported across current implementations.



Received on Wednesday, 2 December 2009 10:10:48 UTC