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 18:21:55 UTC