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:13:54 UTC