structuredPostalAddress questions

[Zindus Development]

A couple of questions about gd:structuredPostalAddress:
http://code.google.com/apis/gdata/docs/2.0/elements.html#gdStructuredPostalAddress

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_protocol.html#Creating
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.

[Donovan Walker]

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 <google....@zindus.com> 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...

[Zindus Development]

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

[Julian (Google)]

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 <google....@zindus.com> 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...

[Zindus Development]

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.

[David Boreham]

Any news on this issue (it's been a few weeks) ?

[Donovan Walker]

There are a couple threads running on this. The skinny is here:
http://groups.google.com/group/google-contacts-api/browse_thread/thread/234043a43f4194f6/e7cdcb51afef20bc?hl=en#e7cdcb51afef20bc

I'd suggest you join the following thread, just so we don't have too
many forks. (also, there's a bit more information on the state of the
contact storage)
http://groups.google.com/group/google-contacts-api/browse_thread/thread/bba78c64b9857bb1/f1c9720bcf741d72?hl=en#f1c9720bcf741d72