ACTION-278 - Propose harmonisation descriptions for Contacts fields

Hi all,

 

The following link contains a detailed proposal to harmonize
descriptions for Contact fields based on our current API and our
discussion last week.

https://spreadsheets.google.com/ccc?key=0AlxhCK-xUsPNdDRGSnFZTTAwU3RVdzh
VZ1dOaUxCaVE&hl=en&authkey=CMzj_YcH

 

Notes:

-          The proposal is based on the assumption that the descriptions
are provided in our spec without explicit references to other
specifications (and I have written all of the descriptions based on
available language from PoCo, vCard and OMA CAB).

-          The interfaces are retained with no changes, and only the
attributes within the interfaces are proposed to be changed in some
cases to be consistent with other formats. There are two types of
changes in attributes.

o   Name change: I have made this decision by using the "majority" rule.
For e.g. if two formats use the same name, I have tried to re-use it in
favor of the naming proposed by the lone format. 

o   Attribute/field change: I did not introduce new attributes but
eliminated some based on either not being crucial or not
consistent/aligned with all the formats in subject. 

 

Based on the proposal, my suggestion is to change the leading sentence
in the Contact interface as below:

 

Change:

"The Contact <http://dev.w3.org/2009/dap/contacts/#contact-interface>
interface captures the properties of a contact object. All properties
included in this interface have a corresponding definition in
[POCO-SCHEMA <http://dev.w3.org/2009/dap/contacts/#bib-POCO-SCHEMA> ]
and are intended to be direct mappings to attributes also defined in
[RFC2426 <http://dev.w3.org/2009/dap/contacts/#bib-RFC2426> ]."

 

To

 

"The Contact interface captures the properties of a contact object. All
properties included in this interface have a corresponding definition in
Portable Contacts [POCO-SCHEMA
<http://dev.w3.org/2009/dap/contacts/#bib-POCO-SCHEMA> ] , IETF vCard
[RFC2426 <http://dev.w3.org/2009/dap/contacts/#bib-RFC2426> ], and OMA
CAB [OMA CAB], thereby allowing the API to be implemented on top of
implementations supporting these different contact formats."

 

 

(The references I think should be moved to the informative section.
Further, I think we can move the second sentence altogether to the Annex
assuming we will provide a mapping of the Contact fields in the API to
these various formats). For OMA CAB, here is the reference: "Converged
Address Book XDM Specification", Version 1.0, Open Mobile Alliance(tm),
OMA-TS-CAB-XDMS-V1_0,   URL:http://www.openmobilealliance.org/")

 

I believe this completes my action-278, and is inline with our
discussion from last week's call.

 

Please note that I will be on vacation starting this Wednesday, and will
not be available for the next 3 weeks. I'm hoping this proposal is
fairly easy to understand and does not require my presentation but if
you have further clarifications on the approach I took, I'll be happy to
discuss it after my return.

 

Richard - I'd appreciate if you can start folding in the proposal (or
parts of it as appropriate) based on the group's discussion this week.

 

 

Thanks,

Suresh

 

 

 


---------------------------------------------------------------------
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.