- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Mon, 03 Feb 2014 18:14:05 +0100
- To: public-geolocation@w3.org, Ms2ger <ms2ger@gmail.com>
Hi Ms2ger, Quoting from http://lists.w3.org/Archives/Public/public-geolocation/2012Jan/0001.html > == 5.1 Geolocation interface == > > > [NoInterfaceObject] > > interface NavigatorGeolocation { > > readonly attribute Geolocation geolocation; > > }; > > > > Navigator implements NavigatorGeolocation; > > would be better written as > > partial Navigator { > readonly attribute Geolocation geolocation; > }; Can you clarify what this would be better? I've seen both approaches used, and I am unclear which one is more appropriate here. > and the preceding sentence > > > Objects implementing the Navigator interface (e.g. the > > window.navigator object) must also implement the NavigatorGeolocation > > interface [NAVIGATOR]. An instance of NavigatorGeolocation would be > > then obtained by using binding-specific casting methods on an > > instance of Navigator. > > should not use 'must', as this is already normatively defined by WebIDL. I'm putting this in my proposed errata for the spec [1]. > Also, the IDL snippets still use the 'in' keyword for method > parameters—this keyword has been removed from the WebIDL spec, as it was > useless. These had been removed. > The Geolocation interface should not have [NoInterfaceObject]. Noted in the errata. > PositionCallback and PositionErrorCallback should use the new callback > syntax, that is: > > > callback interface PositionCallback { > > void handleEvent(in Position position); > > }; > > > > callback interface PositionErrorCallback { > > void handleEvent(in PositionError error); > > }; These ones had been handled. > > The implementation of the getCurrentPosition method should execute > > the following set of steps: > > s/should/must/ Noted in the proposed errata. > PositionOptions should use the dictionary support in WebIDL, and the > default values should probably be specified in the IDL. > With that change, I believe the pre-processing steps in the > getCurrentPosition and watchPosition algorithms can go. Note that Noted in the proposed errata; I assume that to remove the pre-processing steps of "timeout" and "maximumAge", in particular converting negative values to zero, these dictionary members would need to be annotated with [Clamp]; I'm not sure how to deal with the inconsistency between the type "long" and the possible Infinity values, though: http://lists.w3.org/Archives/Public/public-geolocation/2014Feb/0001.html > > If successCallback is the null value, then throw a TypeError. > > isn't necessary; passing null to a 'PositionCallback' argument is > rejected in WebIDL. In order to allow null, one needs to write > 'PositionCallback?'. This had been taken care of. > > The implementation of the watch process should execute the following > > set of steps: > > s/should/must/, again. Noted in the errata. > > In step 5.2.2 of the watch process, the successCallback is only > > invoked when a new position is obtained and this position differs > > signifficantly > > s/signifficantly/significantly/, and don't forget to update the step > number. (A link would perhaps be appropriate.) I believe this had to be taken care of as well. > > == 5.2 PositionOptions interface == > > As noted, this should use a dictionary. The paragraphs starting "In > ECMAScript, …" can probably go away or should be made more obviously > non-normative, as well as all the text about default values. (In fact, > is anything in this paragraph actually normative?) Noted in the errata. > == 5.3 Position interface == > > Again, no point in [NoInterfaceObject]. Shouldn't this be turned into a dictionary instead? If not, I'm not sure what value there is in exposing that interface in the global namespace? > > The coords attribute is optional. > > The address attribute is optional. > > What does that mean, exactly? address was specific to Geo v2; the sentence about "coords" doesn't appear the latest version of v1 at least. > > == 5.4 Coordinates interface == > > [NoInterfaceObject] Again, shouldn't this be a dictionary instead? > > == Address interface == skipping, since this was for v2 > > == 5.5 PositionError interface == > > s/5.5/5.6/ This was only relevant to v2. > Note the warning about integer constants at > <http://dev.w3.org/2006/webapi/WebIDL/#idl-constants>. (for v1, the API was well-deployed before this design decision was made in WebIDL unfortunately) > == References == > > Are these supposed to be sorted in any way? > > [BROWSINGCONTEXT] and other HTML5 references: Ian Hickson is now the > only editor. Noted in the errata. > [URI]: full stop after the title is on the wrong side of the space. Noted in the errata. > [NAVIGATOR]: inappropriately links to a obsolete TR draft of the spec, > link to <http://dev.w3.org/html5/spec/Overview.html> instead (as is done > in the other references). This one had to been fixed. > [DOMTIMESTAMP]: this type is now defined in WebIDL, so no point in > referencing an obsolete specification. Noted in the errata. > [ISO3166]: the label used in the body is [ISO 3166-1]. Not applicable to v1. > [RFC3066]: seems unused. Noted in the errata. > [WEBIDL]: 19 December 2008 is a long time ago, and the spec has been > updated since. This one had been fixed. Thanks a lot for your detailed comments, and sorry they fell through the cracks; I would appreciate your responses e.g. on the dictionary vs interface definitions for Position and Coordinates. Dom 1. http://lists.w3.org/Archives/Public/public-geolocation/2014Feb/att-0002/geoapi-errata.html linked from http://lists.w3.org/Archives/Public/public-geolocation/2014Feb/0002.html
Received on Monday, 3 February 2014 17:14:20 UTC