W3C home > Mailing lists > Public > public-geolocation@w3.org > November 2008

Re: Forward/backward compatibility

From: Doug Turner <doug.turner@gmail.com>
Date: Mon, 24 Nov 2008 13:21:11 -0800
Cc: Erik Wilde <dret@berkeley.edu>, public-geolocation <public-geolocation@w3.org>, Andrei Popescu <andreip@google.com>
Message-Id: <50E8A8A9-4479-457D-AD80-A8C8E0C9FB04@gmail.com>
To: Richard Barnes <rbarnes@bbn.com>


On Nov 24, 2008, at 12:48 PM, Richard Barnes wrote:

> Hi Doug,
>
> First, I'm not entirely sure I understand the distinction between  
> your "options" structure and an extra field in the object that can  
> optionally be null.  Could you clarify?  For the rest of this  
> message, I'm going to assume they're essentially equivalent.


Sure, i am thinking that not all geolocation providers (things that  
provide the browser with location data) will not be able to implement  
various optional pieces of data.  For example, a UA with just a GPS  
device will not have a way of providing a civic address, or a privacy  
rules.  Or maybe a new geolocation provider that we aren't expecting  
that can provide additional information more than either a lat/lon or  
even a civic address.  This pattern allows for extensibility without  
requiring us to spec anything further out.


> With respect to civic addresses, my preference would be for the two  
> forms of location (civic/geo) to be more or less equal, since there  
> are positioning scenarios where one makes sense and not the other  
> (in both directions).  However, as long as geo can be left blank (it  
> will be anyway, when location isn't available), we can talk about  
> adding civic location through an optional extension.


I am not sure it is a good idea to make geo (lat/lon) should be  
optional.  It would be better to provide a default where by any webapp  
can fallback to.


> With respect to privacy rules, it's very important that these be  
> mandatory, in the sense that there must always be a clear set of  
> privacy rules for an object.  This doesn't mean that rule fields  
> always have to be populated: Absence can imply a default rule (as in  
> RFC 4119).  It doesn't make sense to have rules without some  
> interpretation of what it means if the rules aren't there.

So, for every request/response, you are suggesting that we send bits  
over the wire that indicate some sort of rules that the remote site  
should follow?

Although I am pretty sure that I do not think we need something like  
this, couldn't this be something like a flag:

   interface Position {
     .....
     readonly attribute boolean pleaseDontShareMe;
   };

Doug
Received on Monday, 24 November 2008 21:21:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 18:13:30 GMT