RE: Civic Address for V2

I'm an American who lived and worked overseas, and I used Microsoft
products, and I didn't use the Microsoft convention for my address in
the UK because it didn't work.

Microsoft Outlook allows multiple lines for the "Street" field, which I
think is significant.  In many parts of the world, two lines to
represent an address more granular than city simply is not sufficient.
You can see this by going to any major global company's "contact us"
page and looking at the addresses around the world, especially the UK,
Ireland and India.  

Many people and companies decide to force addresses into two lines by
separating different parts of an address with commas, but that can
easily cause confusion and parsing problems because different people
will decide to combine addresses in different ways, and two identical
addresses will be represented completely differently, and it becomes a
programming nightmare to try to reconcile.

My .02 
 

-----Original Message-----
From: public-geolocation-request@w3.org
[mailto:public-geolocation-request@w3.org] On Behalf Of Alec Berntson
Sent: Tuesday, March 03, 2009 10:21 AM
To: Doug Turner; Richard Barnes
Cc: public-geolocation@w3.org
Subject: RE: Civic Address for V2

The format I proposed has been used in Microsoft Office, Live and
Windows. Those products are used by hundreds of millions of users around
the world. For the scenarios that are defined in the spec, Microsoft
believes that this format is sufficient for global usage.

-----Original Message-----
From: Doug Turner [mailto:doug.turner@gmail.com]
Sent: Tuesday, March 03, 2009 10:13 AM
To: Richard Barnes
Cc: Alec Berntson; public-geolocation@w3.org
Subject: Re: Civic Address for V2

yeah, the intent here isn't to imply a specific use case, but rather to
avoid confusion with the well define and more generalized civic address.

Doug

On Mar 3, 2009, at 10:11 AM, Richard Barnes wrote:

> Doug,
>
> "mailingAddress" seems like a weird thing to use, since it implies a 
> single use case.  Civic addresses are of course useful for a lot of 
> other applications -- presence, local information queries, etc.
>
> --Richard
>
>
> Doug Turner wrote:
>> Given that we are considering a reduced civic address, i think it 
>> would be prudent to change the type name to something like 
>> mailingAddress.
>> Also, lets move timestamp to the first attribute on this interface, 
>> if for nothing more than we may add more "position data attributes"
>> following mailingAddress.
>> So,
>> interface Position {
>>  readonly attribute DOMTimeStamp timestamp;  readonly attribute 
>> Coordinates coords;  readonly attribute MailingAddress mailingAddr; }

>> and in the PositionObjects, the attribute should be 
>> MailingAddressOnly.
>> Doug Turner
>> On Feb 27, 2009, at 8:31 AM, Alec Berntson wrote:
>>> Hi,
>>>   As per my Action Item from the December F2F meeting, I'd like to 
>>> put forth a proposal for Civic Address Support in V2.
>>> Civic Address support will be surfaced by including an additional 
>>> object in the Position object next to the cords object. For Example:
>>> interface *Position* {
>>>    readonly attribute Coordinates 
>>> <http://dev.w3.org/geo/api/spec-source.html#coordinates
>>> > coords <http://dev.w3.org/geo/api/spec-source.html#coords>;
>>>    readonly attribute DOMTimeStamp timestamp 
>>> <http://dev.w3.org/geo/api/spec-source.html#timestamp
>>> >;
>>>    readonly attribute CivicAddress addr; // <-this is how it will be

>>> added  };
>>>  1.       The contents of the CivicAddress Object
>>> a.       I propose we use the same fields as the
>>> CivicAddressReport in the Windows 7 Location API. These fields work 
>>> internationally and have no geopolitical issues. They are 
>>> sufficiently expressive to cover virtually any address that would be

>>> used in practice.
>>>
>>> i.      Address1
>>>
>>> ii.      Address2
>>>
>>> iii.      City
>>>                                                           iv.
>>> PostalCode
>>>
>>> v.      StateProvince
>>>                                                           vi.
>>> CountryRegion
>>> 2.       Addition to PositionOptions
>>> a.       The PositionsOptions object needs an option to indicate
>>> which type of data to return. This option will inform the UA of what

>>> the app wishes to see in the Position objects that it is returned.
>>> b.      I propose: Enum {CoordinatesOnly, CivicAddressOnly,  Either}
>>>
>>> i.      CoordinatesOnly = The API only returns position objects
>>> when coords has data, addr is null
>>>
>>> ii.      CivicAddressOnly - The API only returns position objects
>>> when addr has data, coords  is null
>>>
>>> iii.      Either - the API returns a position object whenever
>>> there is data for either CivicAddress or Coordinate data.
>>> Thanks,
>>>   Alec

Received on Tuesday, 3 March 2009 21:01:20 UTC