Hi Charlie, Yes we currently create the formatted version if the client writes only the structured flavor, but not in the other way. If a client writes both flavors we store both flavors as is, without triggering any conversion. So in terms of conversion from structured flavor to formatted one, there will be no change compared to the current behavior.
And yes I ought to write "right enough" heuristic parsing, it's indeed not trivial. regards, Gyorgy On Wed, Aug 5, 2009 at 5:47 PM, Charlie Wood <[email protected]> wrote: > > Gyorgy- > > Thanks for the detailed information. Is point #3 needed though? > > > 3. On modification explicitly clear the flavor the application doesn't > > need. In this case mutation will trigger heuristics to generate the > missing > > flavor. > > The current behavior seems to be that if I insert new structured data, > Google will create the formatted version for me without my needing to > clear the formatted field. > > Also, I'm skeptical that your parsing algorithm can ever be "right". > Names are ambiguous. If a contact has the formatted name "Kramer", is > a first or last name? It's impossible to know. The only "right" > solution IMHO would be to expose only structured fields in the Gmail > Contact Manager. I hope that happens! > > Thanks again, > Charlie > Spanning Sync > > > On Aug 5, 9:53 am, Gyorgy Abonyi <[email protected]> wrote: > > In version 3 we introduced structured names and addresses along with the > > formatted versions, however at the moment we do not provide conversion > from > > formatted to structured at our side. Moreover the behavior of Contact > > Manager in GMail is suboptimal, only the formatted version can be edited, > > and upon edit of the name or address field the structure is destroyed. We > > are working hard to improve the current behavior. > > > > We are intend to introduce heuristic name and address parsing in the API, > > and to help developers to adjust to incoming improvements we recommend to > > follow a few simple rules while developing structured and/or formatted > data > > aware clients: > > > > 1. Read the flavor (structured / formatted) the client is interested > > about. > > 2. If the data type (structured / formatted) your client is interested > in > > is not available, then format or parse the other available data type > for the > > application needs. > > 3. On modification explicitly clear the flavor the application doesn't > > need. In this case mutation will trigger heuristics to generate the > missing > > flavor. > > 4. If the application provides both structured and formatted parts no > > heuristics will be applied and data will be stored as is. > > > > Please note that point 2 is a temporary solution until not all flavors > are > > available in the database. As we intend to back-fill all existing > contacts > > with the missing flavors using our heuristic parsers, this step will > become > > obsolete in the future. Those contacts that already contain both flavors > > will remain unchanged. > > > > Our heuristic parser will be used by Contact Manager in GMail too, so if > the > > user edits the formatted name or address in the contact manager, we will > > generate the correspondent structured components. > > > > And to answer your obvious question, when will it happen? As soon as we > are > > convinced that our parsing algorithm is right. Please expect that the > > heuristic name parsing probably will come earlier than address parsing. > > > > Hope this answers lots of your questions and valuable comments about > > formatted vs. structured names and addresses posted to this group. > > > > Sincerely yours, > > Gyorgy Abonyi, Google Contacts team > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Contacts API" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-contacts-api?hl=en -~----------~----~----~----~------~----~------~--~---
