[Contacts] PortableContacts does not help with formatedName or parsing / etc.

So, I finally got around to looking at portable contacts.

Afaict, it doesn't actually define parsing at all. The text is entirely hand waving about how a system might already know everything it needs to know.



o    displayName:
        The name of this Contact, suitable for display to end-users. Each Contact returned MUST include a non-empty displayName value. The name SHOULD be the full name of the Contact being described if known (e.g. Joseph Smarr or Mr. Joseph Robert Smarr, Esq.), but MAY be a username or handle, if that is all that is available (e.g. jsmarr). The value provided SHOULD be the primary textual label by which this Contact is normally displayed by the Service Provider when presenting it to end-users. 
    name:
        The broken-out components and fully formatted version of the contact's real name, as described in Section 7.3. 
    nickname:
        The casual way to address this Contact in real life, e.g. "Bob" or "Bobby" instead of "Robert". This field SHOULD NOT be used to represent a user's username (e.g. jsmarr or daveman692); the latter should be represented by the preferredUsername field. 
    preferredUsername:
        The preferred username of this contact on sites that ask for a username (e.g. jsmarr or daveman692). This field may be more useful for describing the owner (i.e. the value when /@me/@self is requested) than the user's contacts, e.g. Consumers MAY wish to use this value to pre-populate a username for this user when signing up for a new service. 
7.3.  name Element
The components of the contact's real name. Providers MAY return just the full name as a single string in the formatted sub-field, or they MAY return just the individual component fields using the other sub-fields, or they MAY return both. If both variants are returned, they SHOULD be describing the same name, with the formatted name indicating how the component fields should be combined.
    formatted:
        The full name, including all middle names, titles, and suffixes as appropriate, formatted for display (e.g. Mr. Joseph Robert Smarr, Esq.). This is the Primary Sub-Field for this field, for the purposes of sorting and filtering. 
    familyName:
        The family name of this Contact, or "Last Name" in most Western languages (e.g. Smarr given the full name Mr. Joseph Robert Smarr, Esq.). 
    givenName:
        The given name of this Contact, or "First Name" in most Western languages (e.g. Joseph given the full name Mr. Joseph Robert Smarr, Esq.). 
    middleName:
        The middle name(s) of this Contact (e.g. Robert given the full name Mr. Joseph Robert Smarr, Esq.). 
    honorificPrefix:
        The honorific prefix(es) of this Contact, or "Title" in most Western languages (e.g. Mr. given the full name Mr. Joseph Robert Smarr, Esq.). 
    honorificSuffix:
        The honorifix suffix(es) of this Contact, or "Suffix" in most Western languages (e.g. Esq. given the full name Mr. Joseph Robert Smarr, Esq.). 


Note that implementations are thus free to do whatever.

http://www.plaxo.com/pdata/testClient/ is a "UI" for testing, if you want to see what happens with a sample or two, you can. I used credentials from http://bugmenot.com/view/plaxo.com for testing (and provided some sample Spaniards). I could probably black box determine how *Plaxo* behaves, but that would not be the same as determining how PortableContacts behaves, since it doesn't. Since Plaxo just reflects other sources, it's relatively pointless to feed it data, it'd just reflect however the data was provided (in my case, the data was generated by Microsoft Outlook 2007 as vcf files). 

---------------------------------------------------------------------
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 Tuesday, 30 August 2011 15:45:21 UTC