- From: Max Froumentin <maxfro@opera.com>
- Date: Mon, 09 Nov 2009 16:35:46 +0100
- To: public-geolocation@w3.org
http://www.w3.org/2009/11/02-geolocation-minutes.html#action09 ACTION-32 - Mail the text of http://people.opera.com/~maxfro/geolocation/ for persistence purposes [on Max Froumentin - due 2009-11-09]. See the list below. I have also added the resolution for each item. Note that a couple are missing from the minutes. Look for "??". As agreed, when all the action items are done and the specification updated, I will remove the issues from the list of tests and will update themselves. - "The geographic position information is provided in terms of World Geodetic System coordinates [WGS84]." => This statement should be in a normative section. [resolution: it had already been added in 5.4, so no change] - "The API defined in this specification can be used to retrieve the geographic location of a hosting device. In almost all cases, this information also discloses the location of the user of the device, thereby potentially compromising the user's privacy." => (editorial): replace "can be" with "is", remove "also". [resolution: accepted] - "A conforming implementation of this specification must provide a mechanism that protects the user's privacy and this mechanism should ensure that no location information is made available without the user's express permission." => available to whom? [resolution: fix after resolution of ACTION-26] - "User agents must not send location information to Web sites without the express permission of the user." => This statement should be rephrased for clarity, because some geolocation providers are accessed via the web. Suggest: "User agents must not make location information available through this API without the express permission of the user" [resolution: will be fixed as part of ACTION-26] - "User agents must acquire permission through a user interface, unless they have prearranged trust relationships with users, as described below." => What happens when null is passed for successCallback. Raise an exception immediately? Raise an exception when the callback would normally be called? Do nothing upon successCallback? [Resolution: clarify that an exception to be thrown immediately] - "The user interface must include the URI of the document origin" => Should we really show the full URI, not just the domain? [resolution: specification already says "the URI of the document origin" but reference needs to be updated] - "If the attempt fails, the errorCallback is invoked with a new PositionError object, reflecting the reason for the failure." => "The position of the device could not be determined" is not the same as "...reported an internal error". A GPS unit could be unable to determine a position because it is indoors, but it would not be an internal error. Suggest rephrasing as "The position of the device could not be determined or the location acquisition process reported an internal error that caused the process to fail entirely." or, better, classify errors as: UNKNOWN_ERROR, PERMISSION_DENIED, DEVICE_ERROR, POSITION_UNAVAILABLE. [resolution: drop UNKNOWN_ERROR] -"This operation must first attempt to obtain the current location of the device and invoke the appropriate callback." => (editorial): "appropriate" is too vague. The behaviour should be specified fully, repeating the text from the description of getPosition. [resolution: accepted] - "It then must continue to monitor the position of the device and invoke the appropriate callback every time this position changes." => "Every time" could lead to a very high update rate. Adding "reasonable" somewhere seems sensible. If there is any error while retrieving, then later error disappears, does that consitute a change of position (i.e. will the success callback be called eventually? Clarify "the position changes". For instance, does a change in Position.accuracy alone constitute a change of position? [resolution: draft updated] - "The watch operation continues until the clearWatch method is called with the corresponding identifier" => What does clearWatch() do when an unknown identifier, or an already cancelled one, is passed? [resolution: clarify that an unknown watch ID is a noop.] - "The time that is spent obtaining the user permission must not be included in the period covered by the timeout attribute of the PositionOptions parameter. The timeout attribute must only apply to the location acquisition operation." => It should be made clearer that nothing happens until the user has given permission, and that if the user doesn't give permission the error will be PERMISSION_DENIED and there will not be a TIMEOUT error. [resolution: clarify that nothing happens until user consents] - "If the user grants permission, the appropriate callback must be invoked as described above. If the user denies permission, the errorCallback (if present) must be invoked with code PERMISSION_DENIED, irrespective of any other errors encoutered in the above steps." => Editorial: "encoutered" [resolution: to fix] - "The clearWatch() method takes one argument. When called, the watch process identified by the watchId argument will be stopped and should not invoke any further callbacks." => "will" and "should not" should both be "must" [resolution: accepted] - "The timeout attribute denotes the maximum length of time (expressed in milliseconds) that is allowed to pass from the call to getCurrentPosition() or watchPosition() until the corresponding successCallback is invoked." => The statement could lead the reader to believe that the acqusition only starts when the user has approved, which is not what the rest of the specification mandates [Resolution: clarify that geolocation process does not start before user has approved] - If the PositionOptions parameter to getCurrentPosition or watchPosition is omitted, the default value used for the timeout attribute is Infinity." => This statement contradicts: "If a PositionOptions parameter was present, and its timeout attribute was defined to a non-negative value, assign this value to an internal timeout variable. Otherwise, set the internal timeout variable to 0." elsewhere. [Resolution: second statement wrong, +Infinity is the default value] - "The same default value is used in ECMAScript when the timeout property is omitted." => Is this a special behaviour in ECMAScript, or is the statement necessary? [resolution: it is indeed special behaviour. All ECMAScript statements will be moved together] - "The maximumAge attribute indicates that the application is willing to accept a cached position whose age is no greater than the specified time in milliseconds. If maximumAge is set to 0, the implementation must immediately attempt to acquire a new position object. Setting the maximumAge to Infinity will force the implementation to return a cached position regardless of its age. If an implementation does not have a cached position available whose age is no greater than the specified maximumAge, then it must acquire a new position object. In case of a watchPosition(), the maximumAge refers to the first position object returned by the implementation." => Wording unclear. At least "will force" should be "must". [resolution: ??] - "The coords attribute contains a set of geographic coordinates together with their associated accuracy, as well as a set of other optional attributes such as altitude and speed." => altitudeAccuracy, accuracy, speed, heading, speed should be unsigned. Should heading be given an validity interval? e.g. [0, 360] [resolution: ??] - "The accuracy and altitudeAccuracy values returned by an implementation should correspond to a 95% confidence level. " => What is a confidence level? Why does it matter? [resolution: leave it] - "POSITION_UNAVAILABLE (numeric value 2) The position of the device could not be determined. One or more of the location providers used in the location acquisition process reported an internal error that caused the process to fail entirely. " => "one or more"? If at least one of the providers succeeds, shouldn't that be a success instead? Should it even be mentioned that there can be more than one, given that this API is agnostic to the geolocation device? [resolution: update specification to say "For instance: one or more..."] - "TIMEOUT (numeric value 3) The specified maximum length of time has elapsed before the implementation could successfully acquire a new Position object. " => Editorial: replace with "the length of time specified by the timeout property has elapsed before... " [resolution: replace with "the length of time specified by the timeout property has elapsed without acquiring..."]
Received on Monday, 9 November 2009 15:36:29 UTC