- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sat, 21 Jun 2008 04:54:13 -0700
- To: Ryan Sarver <rsarver@skyhookwireless.com>
- Cc: Ian Hickson <ian@hixie.ch>, Matt Womer <mdw@w3.org>, public-geolocation@w3.org
On Jun 20, 2008, at 8:03 PM, Ryan Sarver wrote: > > Ian, > > Can you expand on why Google feels so strongly that it should be a > part of the Web Apps working group? I think its been stated a number > of times why people feel it belongs in a separate group. IP alone is > enough of a stumbling block and a lot of progress has already been > made in getting the charter proposed and off to a good start. I don't know of any statement as to why this belongs in a separate group. Can you point me to the multiple previous statements you mention? I have heard unofficially that someone made a private complaint to the W3C team about geolocation being covered in the Web Apps WG charter, and for this reason it was removed from the charter and a new group was created. If there are any good reasons that justify this decision made without any visibility or accountability, then by all means let them be stated. Until then, I agree with Ian that this work would better be done inside the Web Apps WG. Regards, Maciej > > > I also agree on the specific call-out of privacy in the opening > paragraph. It's something that seems out of scope of the > specification and more aptly implemented by each vendor. > > rs > > On Jun 20, 2008, at 3:37 PM, Ian Hickson wrote: > >> >> On Fri, 20 Jun 2008, Matt Womer wrote: >>> >>> I'm happy to say that a draft of the Geolocation charter is now >>> available [1], [...] Any and all feedback is greatly appreciated, >>> either >>> here on this list or to myself directly. >>> >>> [1] http://www.w3.org/2008/06/geolocation/charter/ >> >> Here's Google's feedback: >> >> We don't think this should have a separate working group. We would >> rather >> see this done in the Web Apps working group. We feel quite strongly >> that >> this API should not have its own group. >> >> If, and I stress "if", the W3C decides to go ahead and have a >> separate >> working group despite this, then we have the following comments on >> the >> proposed charter: >> >> - We think the first paragraph's emphasis on prviacy could mislead >> people >> into thinking that the API should constrain how user agents expose >> the >> privacy options to the user. We would like the charter to explicitly >> allow the deliverables to defer the user interface aspects of >> privacy, >> and the privacy model in general, to the user agents, within the >> constraints required to obtain interoperability at the API level. >> >> - We think that the charter should not require the working group to >> publish the requirements as an explicit WG note. It should be >> acceptable for us to publish the requirements in the spec itself >> as an >> appendix, or on a wiki, or on our WG home page, etc. >> >> - We believe the timetable to have an unrealistic estimate for the >> time >> from CR to PR. Given the need to create a comprehensive test suite >> and >> to obtain two complete implementations, we believe it would be more >> realistic to expect the API specification to reach PR at the >> earliest >> one year after it enters CR, rather than three months later as in >> the >> current proposed charter. (This also affects the proposed end date.) >> >> - We do not like that the group is expected to have face to face >> meetings >> and telecons. Our experience with other working groups in the past >> few >> years suggests that the group should not be required to meet, and >> that >> asynchronous communication media such as IRC and e-mail should be >> sufficient. >> >> - We are not sure that the charter should explicitly expect the >> group to >> follow the AWWW and CharMod specifications. Recent developments (in >> particular in the HTML5 group) have suggested that these >> specifications >> are somewhat unrealistic in terms of the constraints put on >> technologies intended for wide deployment on the Web. >> >> - We do not believe there should be a member-only mailing list. A >> public >> group should be exclusively public. >> >> - We believe that the decision policy should be ammended to >> explicitly >> grant specification editors broad responsibility for the >> specifications >> that they edit, requiring them to address the needs of anyone >> bringing >> feedback to the group, as well as requiring them to base their >> decisions on technical merit and research rather than on votes; we >> think that that decisions should explicitly not be derived from >> consensus. We think that the decision policy should say that the >> group >> has the right to replace the editor based on a vote, so as to >> safeguard against editors who fail in their responsibilities to the >> group. >> >> - We think that participation should be open to anyone on the same >> basis >> as the HTML working group. >> >> Cheers, >> -- >> Ian Hickson, on behalf of Google >> >> > > >
Received on Saturday, 21 June 2008 11:54:56 UTC