- From: Alec Berntson <alecb@windows.microsoft.com>
- Date: Tue, 3 Mar 2009 10:51:28 -0800
- To: Andrei Popescu <andreip@google.com>, Richard Barnes <rbarnes@bbn.com>
- CC: "public-geolocation@w3.org" <public-geolocation@w3.org>
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