Re: Errors in Geolocation Rec

Some comments inline. Thanks for working through these Dominique.

/m


On Mon, Feb 3, 2014 at 5:14 PM, Dominique Hazael-Massieux <dom@w3.org>wrote:

> 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.
>

It seems effectively the same thing, expressed more succinctly. If that's
not correct, I'd love to hear the details. Fwiw, partial interfaces seem
like the more recent syntax.


>
> > 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?
>

As you noted, it can't be a dictionary. But I have the same question: why
expose it 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
>
>
>
>
>