Re: Forward/backward compatibility

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.

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.

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.

--Richard




Doug Turner wrote:
> 
> Any thoughts on supporting geopriv address objects and privacy via 
> position options:
> 
> 
> On Nov 13, 2008, at 12:06 PM, Doug Turner wrote:
> 
>>
>> On Nov 13, 2008, at 11:54 AM, Erik Wilde wrote:
>>
>>>
>>> Richard Barnes wrote:
>>>> So I would be much more comfortable if a geodetic location were 
>>>> optional (at least in v2), since there are deployments were it would 
>>>> be detrimental (inaccurate and unnecessarily complex) to add 
>>>> geodetic location.  I'm not sure how do go from a geodetic-only API 
>>>> to one where geodetic is optional in a backwards-compatible fashion.
>>>
>>> my proposal would be to solve this by creating a more comprehensive 
>>> API and model of location, which optionally may point to a lat/long 
>>> API, if that is a kind of location that is required and available in 
>>> a scenario. assuming that the lat/long API itself might evolve into a 
>>> more general location API would require it to add so many constraints 
>>> to it (such as almost everything in version 1 would have to be 
>>> treated as optional), that in my opinion it would be unlikely that it 
>>> actually would be implemented correctly. which would mean that you 
>>> would end up with v1 APIs not behaving correctly and thus breaking v2 
>>> code.
>>>
>>> going for the low-hanging fruit is a good strategy, but i think it is 
>>> important to realize that there are many more available, and we 
>>> should be careful to not negatively impact the ability to get those 
>>> fruit a little later...
>>>
>>> cheers,
>>>
>>> dret.
>>>
>>
>>
>>
>> I am thinking along the lines of adding additional options to the 
>> PositionOptions to request addtional geolocation information from any 
>> backend provider.  For example, if you want to get a civic address, 
>> you would do something like (hand waving):
>>
>> var options = {
>>  additional_options = "address";
>> };
>>
>> function a(pos) {
>> var address  = pos.options("address");
>> alert(address.zipcode);
>> }
>>
>> navigator.geolocation.watchPosition(a, b, options);
>>
>> I know the names of the attributes are not right, but I hope you get 
>> the idea. it would allow the extensiblity required for v2 and address 
>> the concerns about "dropping geopriv info".
>>
>> Thoughts?
>>
>>
> 
> 
>

Received on Monday, 24 November 2008 20:49:17 UTC