RE: Contacts API: vCard vs. PoCo

On Wed, 11th Nov 2009 at 01:52, 이강찬 (Kangchan) [chan@etri.re.kr] wrote:
>
> My opinion is that it is need to discuss the use case of contact API.

I agree and we need to include use cases in to the Contact API and redefine the spec if necessary. Do you have use cases to share?

> Also, if necessary, the comparison table of the contact
> related specification is required (based on the use cases and
> requirements).

I propose to support a superset. In this case, fields from any vCard, OpenSocial or any subsetted implementations should be mappable to some or all Contact API attributes that are currently defined in the spec. The current spec does not require all implementations to support all fields. I'm wary of approaching this as an ontology. What would an ontology provide that the current atributes in the specification do not?

> It will be very helpful to decide the design of contact API.
> (superset vs. common denominator)

If you could propose a common denominator set of attributes on the list that would be helpful. I worry that we would not be able to agree on a suitable subset. What goes in? What stays out...and why?

The current approach is to provide a well-defined and extensive superset to avoid implementations using different naming for the same extended fields based around the Portable Contacts API (i.e. vCard and OpenSocial attributes are well-defined from the beginning).

> One more thing is that I suggest to support lunar calendar
> system on birthday attribute of current contact API (include
> date class in calendar API).
> It will be very helpful to deploy DAP's in some area(Asia/Pacific).

I understand this requirement. However, the problem is larger than just the Chinese (or Japanese or Vietnamese) lunar calendar system. If we go down this route and if we want to do a complete job we may also need to consider some or all of the following calendar systems: Julian, Hebrew, Islamic, Persian, Mayan, Bahá'í, French Republican and Indian Civil.

Unless we want to bake in Date/Time conversion to our APIs and since conversion from the Gregorian calendar to all of these calendrical systems is possible through mathematical algorithms [1] I would prefer to focus around a well-defined time system - at the moment this is ISO-8601.

I have been and am still wary of including the Javascript Date class in the Contacts or Calendar API. It assumes that an implementation has the ability to manipulate a complex Javascript object from a non-browser based container (i.e. create a date and then output the result as the Chinese Lunar Calendar representation of the date). Presently the API only focuses around Objects, Arrays, Strings, Integers and booleans and I'd prefer to keep it this way in both the Contacts and Calendar API.


Kind Regards,

Richard

 
[1] http://www.cup.cam.ac.uk/catalogue/catalogue.asp?isbn=9780521702386 <http://www.cup.cam.ac.uk/catalogue/catalogue.asp?isbn=9780521702386>