Re: Civic Address for V2

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:11:53 UTC