- From: Doug Turner <doug.turner@gmail.com>
- Date: Tue, 3 Mar 2009 10:22:40 -0800
- To: Andrei Popescu <andreip@google.com>
- Cc: Richard Barnes <rbarnes@bbn.com>, Alec Berntson <alecb@windows.microsoft.com>, "public-geolocation@w3.org" <public-geolocation@w3.org>
i was thinking that there might be an optional |civicAddress|
attribute at a later point. so, having a prefix provides consistency.
On Mar 3, 2009, at 10:17 AM, Andrei Popescu wrote:
> Guys, what is wrong with 'address'? Why does it have to have a prefix?
> :) Given the context, I doubt anyone will confuse this with an IP
> address or something else. There is also the definition of the
> attribute in the spec, which will make it clear what sort of address
> we're talking about.
>
> Andrei
>
> On Tue, Mar 3, 2009 at 6:13 PM, Doug Turner <doug.turner@gmail.com>
> wrote:
>> 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:23:21 UTC