Structured Postal Addresses
Rolf Schäuble
I noticed that the addresses (postalAddresses) in the contacts API are
just a text field. Considering how different address formats are in
different countries, it would be quite difficult to analyze this field
to extract the individual data items (like street, house number,
postal code).
Are there any plans to structure this, i.e. making an element with
subelements out of this single text element, so that a client can
easily get e.g. the street name?
I believe that this would make it much easier for syncing
applications, among others.
Best regards
Rolf
Julian Bond
>I noticed that the addresses (postalAddresses) in the contacts API are
>just a text field. Considering how different address formats are in
>different countries, it would be quite difficult to analyze this field
>to extract the individual data items (like street, house number,
>postal code).
>
>Are there any plans to structure this, i.e. making an element with
>subelements out of this single text element, so that a client can
>easily get e.g. the street name?
It's really disappointing that Google chose to create yet another
profile description schema rather than using an existing format. The
most widely used is probably VCard which has already done a lot of work
on structuring worldwide addresses. Something like this
- Country
- Postcode / Zipcode //Optional. Not all countries use one
- State/County //optional not all addresses have one
- City/Town //optional not all addresses have one
- Address lines // plain text as its often multiline and unstructured
--
Julian Bond E&MSN: julian_bond at voidstar.com M: +44 (0)77 5907 2173
Webmaster: http://www.ecademy.com/ T: +44 (0)192 0412 433
Personal WebLog: http://www.voidstar.com/ skype:julian.bond?chat
Dispose Thoughtfully
Rolf Schäuble
Additionally, the same of course applies to the name of the contact.
Right now it's just one string. Like with addresses, splitting this
into first name, last name, suffix etc. is quite complicated and
depends on the locale.
I really hope that the current state of affairs is just a result of
not putting much work into the contact management part of GMail.
Comparing it with the rest of GMail, or with the Google Calendar, it's
really lacking in functionality and refinement. However, it's still
better to have it in this state than none at all, so I don't want to
complain too much :)
I just hope that this part will be refined in the future, including
migrating it to a proper schema.
When I compare the offerings of Yahoo and Google, then it's really
only the contacts manager that looks bad on Google's side. Otherwise,
Google's software really rocks!
On 16 Mrz., 09:28, Julian Bond <julian_b...@voidstar.com> wrote:
> Rolf Schäuble <rolf.schaeu...@gmail.com> Fri, 14 Mar 2008 20:45:28
dbrattli
provided you with a vCard that looked something like this:
BEGIN:VCARD
VERSION:2.1
FN:Firstname Lastname
LABEL:Postal Address ...
...
END:VCARD
Is FN any better than title, or is LABEL any better than
postalAddress? I can understand that you want more information in the
contact entry, but i'm not sure that vCards are the best solution. You
don't have to look further than IM to see that vCard properties such
as X-MSN and X-GOOGLE-TALK are a mess. I also want more information in
the Contacts XML entry, but I don't want any vCards. I was actually a
bit disappointed to find that the Calendar API contained an iCalendar
recurrence block instead of XML.
-- Dag
Julian Bond
>Why should a vCard be any better than XML? Would it be better if they
>provided you with a vCard that looked something like this:
There's plenty of instances of VCard being expressed as XML as well as
hCard. http://www.w3.org/TR/vcard-rdf W3C Note 22 February 2001 The
issue is not VCard vs XML vs RDF, it's whether to use VCard as a basic
schema.
>Is FN any better than title, or is LABEL any better than
>postalAddress? I can understand that you want more information in the
>contact entry, but i'm not sure that vCards are the best solution. You
>don't have to look further than IM to see that vCard properties such
>as X-MSN and X-GOOGLE-TALK are a mess.
Indeed. And just as vCard is somewhat out of date with current practice
now, so proprietary extensions to Vcard don't exactly help.
I do find it amazing that there really isn't a de facto standard for
describing account profiles and hence people. Probably the widest used
is MS Outlook layout CSV, but CSV really isn't suitable for a data
transport between systems. After that, VCard probably gets used more
than any other. So it's understandable that Google felt the need to
create yet another one even if it is irritating. I wouldn't mind so much
if the gd: schema was actually complete and comprehensive because it
might become a de facto standard. But right now it look woefully
incomplete and thin.
--
Julian Bond E&MSN: julian_bond at voidstar.com M: +44 (0)77 5907 2173
Webmaster: http://www.ecademy.com/ T: +44 (0)192 0412 433
Personal WebLog: http://www.voidstar.com/ skype:julian.bond?chat
Discontinue Use If Rash Persists
helge
> Is FN any better than title, or is LABEL any better than
> postalAddress?
is used alongside N as the formatted name of N, which of course is
structured. The same goes for LABEL. LABEL does not represent the
primary address of the vCard, its just the formatted ADR element for
printing on letter labels.
Actually I know no client/server which exports just LABEL and FN, but
not ADR and N. In fact the reverse is common (sometimes this is an
issue because a LABEL is not necessarily a 1:1 representation of an
ADR).
Google contacts do not provide N or ADR (or a similiar structural
representation) which is very disappointing (but reflects the UI).
Helge
PS: of course you are right that the data format does not matter
*that* much in the actual issue. The problem is not that Google uses
XML instead of vCard, but that the storage does not capture structured
addresses.