- 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