W3C home > Mailing lists > Public > public-geolocation@w3.org > March 2009

Re: Civic Address for V2

From: Richard Barnes <rbarnes@bbn.com>
Date: Tue, 03 Mar 2009 13:18:21 -0500
Message-ID: <49AD746D.2030005@bbn.com>
To: Doug Turner <doug.turner@gmail.com>
CC: Marc Linsner <mlinsner@cisco.com>, Alec Berntson <alecb@windows.microsoft.com>, "public-geolocation@w3.org" <public-geolocation@w3.org>
I think Marc's point is that by making things any "simpler" than RFC 
5139 (which is already a lot simpler than, say, xAL), you're ruling out 
its usage in large parts of the world (including parts of both Europe 
and Asia).  So it really is a US-centric restriction.

--Richard




Doug Turner wrote:
> Hi Marc,
> 
> Yeah, we aren't going to have USA_ prepended to anything in the 
> geolocation api.  I how about something like |simpleAddress|.
> 
> Doug
> 
> 
> 
> On Mar 3, 2009, at 9:53 AM, Marc Linsner wrote:
> 
>> Doug,
>>
>> I think what we’re trying to say it should be ‘USA_MailingAddress’ as 
>> it doesn’t work for significant parts of the world.
>>
>> Several countries were represented in the formulation of the 5139 
>> object, all of which stated, ‘If you want to sell you product in our 
>> country, this is what you have to do.’
>>
>> YMMV
>>
>> -Marc-
>>
>>
>> On 3/3/09 12:20 PM, "Doug Turner" <doug.turner@gmail.com> 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:19:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:52 UTC