Re: GEOPRIV and the W3C Geolocation API

I'm wondering what the value is of having this API be a W3C standard.  
The approach of the UA developers seems to be to apply the W3C  
imprimatur to a minimal set of functionalities that are already in  
existence across the browsers. Couldn't the UAs just get together and  
agree on the interface they want and publish it, without going through  
the W3C process?

To me, the W3C standardization process is not only valuable for  
disambiguating existing conflicting implementations, but also in  
transcending the needs (and the developers) of today. But the  
mentality here seems to be that unless some functionality has already  
been implemented and is already in wide use, it's not worth  
standardizing, whether or not it might meet a need, fulfill a goal, or  
promote a preferred way of doing things down the road. Why can't the  
standards process support the progress of ideas to the point where  
they are in wide use, rather than being limited to waiting until  
they're already accepted and then rubber-stamping them?

What will UAs do when, the day after v1 of the spec is published by  
the W3C without privacy rules, they receive a Geopriv object? If they  
were just eschewing to their own agreed-upon standards, I can't say  
I'd be happy about the fact that they might throw away the object's  
privacy rules, but at least that behavior wouldn't be sanctioned by  
the world's leading web standards body. I'm curious as to why there's  
a need to lend W3C credence to a spec that is limited to existing  
functionality and makes few provisions for what may be needed or  
helpful in the future.

Alissa

On Nov 11, 2008, at 1:40 PM, Doug Turner wrote:

>
>
> On Nov 11, 2008, at 10:37 AM, Aaron Boodman wrote:
>
>> On Tue, Nov 11, 2008 at 10:19 AM, Richard Barnes <rbarnes@bbn.com>  
>> wrote:
>>> On the contrary, the point of APIs being compatible with RFCs is  
>>> to minimize
>>> "transcoding" between two standards.  The API specifies the  
>>> formats and
>>> interactions within a host, and the RFC specifies what formats and
>>> interactions on the wire.
>>>
>>> If it's going to use network services, the code that implements  
>>> the API has
>>> to think in API terms on one side and in RFC terms on the other.   
>>> If these
>>> are dramatically different (say, if the email API wanted addresses  
>>> as images
>>> for anti-spam purposes), then the API has to translate.  The point  
>>> of making
>>> the API compatible with the RFC is to make this translation easy.
>>>
>>> If you know that you're going to have code that has a particular  
>>> protocol on
>>> the back end, then having APIs that match up well against the  
>>> corresponding
>>> RFCs minimizes the risk of mis-interpretation and makes  
>>> interoperability
>>> easier.  In this case, given that GEOPRIV protocols are the Internet
>>> standard protocols for a host to acquire location, it's very  
>>> likely that
>>> code will want to use them on the back end, so it makes sense for  
>>> the API to
>>> be compatible with them.
>>
>> It's true that API design can sometimes be limited by the underlying
>> wire format. However, that is not a problem here. If geopriv became
>> very popular and we wanted to add support for it, that would be easy
>> to do in a v2 of this API. We'd only need to add a rules object to  
>> the
>> Position interface.
>>
>> - a
>
> +1

--
----------------------------------------------------
Alissa Cooper
Chief Computer Scientist
Center for Democracy and Technology
1634 I Street NW, Suite 1100
Washington, DC 20006
202 637 9800
fax 202 637 0968
acooper@cdt.org
http://www.cdt.org

Received on Wednesday, 12 November 2008 21:39:10 UTC