Re: Civic Address for V2

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:17:52 UTC