W3C home > Mailing lists > Public > public-geolocation@w3.org > March 2009

Re: Civic Address for V2

From: Andrei Popescu <andreip@google.com>
Date: Tue, 3 Mar 2009 18:44:05 +0000
Message-ID: <708552fb0903031044q37ab6579xd863c183e2f0f6e2@mail.gmail.com>
To: Richard Barnes <rbarnes@bbn.com>
Cc: Alec Berntson <alecb@windows.microsoft.com>, "public-geolocation@w3.org" <public-geolocation@w3.org>
On Tue, Mar 3, 2009 at 3:26 PM, Richard Barnes <rbarnes@bbn.com> wrote:
> Hey Andrei,
> I think we're mostly in agreement.  A few more points inline:
> <trimmed/>
>> I understand this goal. However, I feel that this isn't as important
>> for our spec as providing a format that is easy to understand and code
>> against.
> Maybe I'm just too accustomed to the IETF civic address standards, but it's
> not clear to me that these goals are in conflict.  I'm pretty sure that web
> sites that have to deal with civic addresses in a serious way are already
> using the official address databases in the US.  (E.g., when Amazon checks
> an address you enter and says "Is this what you meant?" -- the thing you
> meant is from the DB)  There's already a standard translation between those
> addresses and the IETF format, defined in RFC 4776.  That means that there
> are websites out there already that understand addresses that are equivalent
> in complexity to the RFC 4119 addresses (actually, more complex).
> Is there a specific part of the RFC 4119 civic address spec that you find
> confusing?

Well, for starters, the naming of the fields is non-intuitive (to say
the least). If they were named like this in order to be language
independent, I think that is not a requirement for this spec since the
rest of the API is already in English. I also think that some of the
fields may also be reasonably coalesced. Here's a proposal:

country - country
a1 - region
a2 - county
a3 - city
a4 - can be coalesced with city
a5 - premises ('Belgrave House')
a6 - street
prd,pod,sts - can be coalesced with street (e.g. 'Carriage Drive North')
hno - street number
hns - coalesced with street number  (e.g. '52B')
lmk, loc, flr, nam - can be combined into a separate field ('details'?)
postalcode - postalcode

So now we have 9 fields with understandable names. Alec's proposal had
6 fields. Perhaps we can expand his proposal to accommodate the
missing fields as a compromise?

What do you think?

Received on Tuesday, 3 March 2009 18:44:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:52 UTC