RE: ISSUE-98: contactsDataModel (from Suresh)

-----Original Message-----
From: Robin Berjon [mailto:robin@robineko.com] 
Sent: Wednesday, September 29, 2010 8:11 AM
To: Suresh Chitturi
Cc: Rich Tibbett; public-device-apis@w3.org; Frederick.Hirsch@nokia.com
Subject: Re: ISSUE-98: contactsDataModel (from Suresh)

On Sep 29, 2010, at 02:28 , Suresh Chitturi wrote:
> From: public-device-apis-request@w3.org
[mailto:public-device-apis-request@w3.org] On Behalf Of Rich Tibbett
> 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,
> 
> Suresh>> Thanks for clarifying this. Unfortunately, this is not the
case when you read the spec. I would strongly suggest that we re-use the
descriptions from PoCo if they are appropriate rather than referencing
them. This will ease a lot of things and will not give a wrong message
to the audience. I remember you did have the descriptions in the
previous versions.

Copying rather than referencing is by and large a bad idea. If there is
existing text that is good, and if that text is being actively
maintained so that bugs are fixed, we should reference it so that we
benefit from the bug fixes and don't create gratuitous divergences. This
is basic editorial good practice.


Suresh>> Generally, I would agree that referencing is the best approach.
However, the issue we have at the moment is that no single format has
emerged as the consensus one. On the other hand, keeping our own
descriptions would make sense going forward, as we can keep control on
how our API/format evolves, and don't have to worry about extensions.
This is another reason to have a very simple set of fields to start with
and push everything else under "extensions".

If there is a concern that some audiences might misinterpret this as a
specific message, then we can simply clarify the situation with an
appropriate introductory paragraph.

> The attributes used in the W3C Contacts API equally belong to the
vCard  
> standard.
> 
> Suresh>> The key is which version of vCard. If you are saying vCard
4.0 I don't think it is good idea which is not frozen and not as
commonly used and this is the same case with PoCo and CAB. Therefore,
the push for a "minimum" set that can map well to all the candidate
formats, and this is the best we can position ourselves at the moment.

>From what I gather there's some level of convergence towards vCard 3.
"Frozen" is an attribution subject to qualification. An IETF draft in
Last Call can be considered more stable and more frozen than a rushed
specification from other organisations because the IETF is strong on
interoperability.

Suresh>> Right, vCard 2.1/3 appears to be the one (or is) most stable
one out there. Having said this I don't know if this is the format we
want to use in our spec.

Rather than trying to categorise entire specifications which mostly
tends to lead to organisational posturing, I would rather we looked at
specific issues with what we currently have, and see if there are any
real issues, and if so how we can address them, on a case by case basis.

--
Robin Berjon
  robineko - hired gun, higher standards
  http://robineko.com/





---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Wednesday, 29 September 2010 14:19:12 UTC