- From: Matt Womer <mdw@w3.org>
- Date: Fri, 6 Jun 2008 15:49:03 -0400
- To: public-geolocation@w3.org
Hi all, While working on the draft charter, I had already given some thought to this "DOM based API" issue and related issues, and I'd like to get feedback. I've written that: 1. We are required to produce an ECMAScript interface 2. This interface may or may not inherit from DOM interfaces 3. We may explore exposing location information via markup or HTTP headers Some thoughts and rationale for each: On #1, I've spoken to some of you, and all have expressed interest in the interface being ECMAScript, but for some deployed mobile systems (particularly those that don't have ECMAScript) this is a complete non- starter. Thoughts? This does relate to #3 though, and I'll elaborate more there. Before digging into item 2, I want to mention that on the Web there seems to be a slang-like usage of the term "DOM interface". As near as I can tell it is mistakenly used to mean an interface that's available via a global Object, but isn't necessarily related to the DOM and it's interfaces. I'd like to suggest that we be careful in our use of terms like "DOM interface", and restrict it to mean those interfaces that are related in some way to the DOM. (I realize that's not a very strict definition, but I think it solves the issue). Otherwise confusion abounds. I put number 2 in the draft of the charter to indicate that we will at least discuss the pros and cons, and arrive at a conclusion of DOM based, not DOM based (or both I suppose...). From talking with some of you I wasn't sure we would get any pro-DOM based input, and so considered dropping it, but given the discussion thus far today, it seems like it is worthy of exploration. Exploring it is worthwhile if for no other reason than to be able to justify our decision one way or the other. Regarding number 3, thus far I haven't associated a specific work item to this 'exploration', so it is flimsy. I include this based on feedback from some of you, as well as exploring currently deployed systems, and other places, such as the IETF geo-header draft [1]. I suspect that creating anything in these realms would be out of scope, but I believe it would be useful to explore and synchronize where possible, and perhaps produce a WG Note explaining the differences. -Matt [1] http://tools.ietf.org/html/draft-daviel-http-geo-header-05 On Jun 6, 2008, at 2:15 PM, Maciej Stachowiak wrote: > > > On Jun 6, 2008, at 10:55 AM, Doug Schepers wrote: > >> Hi, Folks- >> >> (- public-webapi, just to reduce cross-posting) >> >> >> Maciej Stachowiak wrote (on 6/6/08 12:58 PM): >>> On Jun 6, 2008, at 7:55 AM, Mark Baker wrote: >>>> On Thu, Jun 5, 2008 at 4:20 PM, Andrei Popescu >>>> <andreip@google.com> wrote: >>>>> >>>>> I am interested in working on a specification of a DOM API that >>>>> allows >>>>> Web pages to access the user's geolocation information (e.g. >>>>> latitude >>>>> and longitude). >>>> >>>> I'm very glad to see somebody mention using the DOM API for this >>>> kind >>>> of information, right off the bat. I'm a big believer in reuse, >>>> and >>>> feel that this API is an obvious candidate for reusing the DOM, >>>> i.e. >>>> providing a "Location" Javascript object that's also a DOM >>>> Document. >>> I don't understand why you would want the "Location" object to be >>> a DOM Document. (It needs a better name, by the way, so it doesn't >>> conflict with the Location object that is window.location.) And I >>> don't think that is what Andrei had in mind, as I understand it, >>> he just wants an API that aligns well with the DOM, not >>> necessarily one that makes non-markup information appear to be >>> part of a Document. >> >> I think I read the idea of hanging it off the Navigator object >> instead of the Document or Window object, which puzzled me... a >> request for access comes directly from a particular site, so >> granting it should apply only to the requesting tab/window. > > The navigator object has traditionally been the place to hang > information and APIs that are not specific to a particular frame or > document (like UA version info, available plugins, online/offline > status, etc). But I could see doing it either way. > >> >> >> >>> I think presenting geolocation info as a Document would have the >>> disadvantages of more memory use and less obvious access for >>> authors. >>> What are the advantages? >> >> I'm not sure I'd count it as an advantage, but there is the way >> KDDI [1], DoCoMo [2], and (as information) Microformats [3] deals >> with this in markup. I'm not suggesting we align around that, more >> mentioning it for context. > > Interesting... > >> <off-topic> >> I'm sure it's out of scope for the Geolocation API, but it might be >> interesting to discuss how location could be codified in markup >> such that if you found a resource that had a specific location (a >> web page for a pizza place), a user could find the relation between >> their current location and that place. I know, more of a service, >> but I thought I'd toss it out there. >> </off-topic> >> >> [1] http://sideshowbarker.net/gps/ >> [2] http://www.nttdocomo.co.jp/english/service/imode/make/content/ >> gps/ > > These both seem to be a way to send location info to a server along > with an HTTP request (via an HTML extension), not a client-side API. > There doesn't seem to be a document representation of the location > info itself, it is just a string sent as an extra request parameter, > at least in the DoCoMo case. > >> [3] http://microformats.org/wiki/geo > > Interesting, though I don't think this includes all the info we'd > want in a geolocation response. > > Regards, > Maciej > >
Received on Friday, 6 June 2008 19:49:42 UTC