I know you said you're working on it, thanks for letting us know. Being a eager beaver, I was hoping that there was a way of using the parts of v3 that work ok (eg new fields) while avoiding the work-in-progress features (unstructured parsing). This is what I found.
If you create a contact containing: gd:structuredPostalAddress/gd:formattedAddress then the <entry> returned in the 201 response contains: gd:structuredPostalAddress/gd:formattedAddress That's expected of course. But in the subsequent GET, the <entry> does *not* contain gd:structuredPostalAddress That's no good at all - it means there complete loss of the postal address! So I have come to the conclusion that the API v3 is unusable, because effectively it doesn't support postal addresses of any kind - structured or unstructured. Which means that the best course of action is ... patience :-) Leni. Julian (Google) wrote: > Hi, > > Thank you for the feed back, as I mentioned in other posts, there has > been a lot of work upgrading and improving the unstructured data > parsing, Address parsing is in our top priorities but it will take few > more weeks, we will keep you posted here in the group. > > Cheers, > Julian > > On Jun 19, 11:43 pm, Zindus Development <[email protected]> wrote: >> Donovan - like you, I'm just getting gd:formattedAddress back, not the >> address parts. >> >> The current behaviour looks and feels like a bug to me because: >> a) it's inconsistent with the treatment of gd:name, and >> b) it seems to be at variance with the docs' >> (although the 'may' offers some wiggle >> room):http://code.google.com/apis/contacts/docs/3.0/migration_guide.html#St... >> Modifications of gd:postalAddress by old clients are reflected >> in the gd:formattedAddress, and they may also trigger heuristic >> parsing with the goal of obtaining the remaining components >> of gd:structuredPostalAddress. >> >> This, together with the mishandling of gd:country make me wonder if this >> v3 API needs some time to shake out and stabilise. >> >> To the googlers on this list: please don't take this as negativity. The >> v3 features are fantastic, it just feels like they might have been >> released a bit prematurely. >> >> Leni. >> >> Donovan Walker wrote: >> >> > Leni, >> > >> > if you pull addresses from google, are you getting anything other than >> > the formattedAddress sub field in gd:structuredPostalAddress ? >> > >> > On Jun 18, 4:49 pm, Zindus Development <[email protected]> wrote: >> >> A couple of questions about >> gd:structuredPostalAddress:http://code.google.com/apis/gdata/docs/2.0/elements.html#gdStructured... >> >> >> >> 1. is gd:formattedAddress parsed into component parts? >> >> >> >> When a new contact containing a >> >> gd:structuredPostalAddress/gd:formattedAddress element is PUT, the >> >> returned contact doesn't contain any elements for the address parts like >> >> gd:street gd:city etc. >> >> >> >> This seems to be inconsistent with the handling of the gd:name element, >> >> where creating a new contact with gd:name/gd:fullName returns a contact >> >> containing the name parts: givenName, familyName etc. >> >> >> >> Is gd:formattedAddress supposed to be parsed into it's component parts >> >> by the API? And if so, when? >> >> >> >> 2. is gd:country broken? >> >> >> >> PUT the contact given as an example >> here:http://code.google.com/apis/contacts/docs/3.0/developers_guide_protoc... >> >> and the API returns: >> >> 400 Bad Request >> >> [Line 34, Column 42, element gd:country] Unrecognised element. >> >> >> >> Remove the gd:country element and it works fine. >> >> >> >> Leni. >> > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
