- From: Andrei Popescu <andreip@google.com>
- Date: Tue, 3 Mar 2009 18:44:05 +0000
- 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?
Thanks,
Andrei
Received on Tuesday, 3 March 2009 18:44:46 UTC