- From: Richard Barnes <rbarnes@bbn.com>
- Date: Tue, 03 Mar 2009 13:18:21 -0500
- 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