W3C home > Mailing lists > Public > public-geolocation@w3.org > February 2014

Errors in Geolocation Rec

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Mon, 03 Feb 2014 18:14:05 +0100
Message-ID: <1391447645.5866.203.camel@cumulustier>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:51:07 UTC