RE: Civic Address for V2

I suppose an important attribute is which fields are required, if any. I imagine that some UAs will not have sources of data for some of the fields.

-----Original Message-----
From: Andrei Popescu [mailto:andreip@google.com]
Sent: Tuesday, March 03, 2009 10:44 AM
To: Richard Barnes
Cc: Alec Berntson; public-geolocation@w3.org
Subject: Re: Civic Address for V2

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:52:23 UTC