- From: Alissa Cooper <acooper@cdt.org>
- Date: Wed, 12 Nov 2008 16:38:26 -0500
- To: Doug Turner <doug.turner@gmail.com>
- Cc: Aaron Boodman <aa@google.com>, Richard Barnes <rbarnes@bbn.com>, Andrei Popescu <andreip@google.com>, public-geolocation <public-geolocation@w3.org>
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