- 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