Geolocation V2 and backwards compatibility

At the recent face-to-face meeting we talked a lot about how the Geolocation
V2 API [1] would remain backwards compatible with the V1 API. The additional
features we'd like to add for the V2 API are ...
- Support a new civic address property. Implementations must be able to
invoke the success callback with either a valid civic address, a valid set
of coordinates or both. This is relevant for implementations which can not
do a civic address lookup from a set of coordinates, or which rely on
user-entered civic address data.
- Support the case where an implementation can provide some coordinate data,
but not all of the latitude, longitude and accuracy properties, which are
required in V1. This is relevant for implementations which have access to,
for example, a speedometer or altimeter, but no source of position
information. See ISSUE-7 [2] which mentions this problem for the velocity
components.

When backwards compatibility was discussed previously [3], one suggested
approach was to use the DOM hasProperty() API to distinguish between the two
APIs. This would mean that V2 implementations would have to be backwards
compatible with webpages written for the V1 API. Webpages using the V2 API
would use hasProperty() before relying on V2 features. However, we thought
it would be better to find a solution which avoided the need for versioning.
This means that in addition to V2 implementations being backwards compatible
with webpages written for the V1 API, the API needs to be such that webpages
written for the V2 API still work with V1 implementations.

To achieve this, we propose the following ...
- Make the Position.coordinates property optional, as well as its latitude,
longitude and accuracy properties.
- Add an optional Position.address property for the civic address, the
properties of which are all optional.
- Add a boolean PositionOptions.requireLatitudeLongitudeAccuracy property,
which defaults to true. When this flag is true, the
Coordinates.latitude, Coordinates.longitude and Coordinates.accuracy
properties are all guaranteed to be non-null, and hence Position.coordinates
is non-null too. This means that the V1 behaviour is maintained and the
success callback can only be invoked when a valid latitude, longitude and
accuracy are available. When this flag is false, this restriction is lifted,
all properties are optional, and webpages have to check each property before
using it. This allows implementations to provide, for example, a civic
address or altitude without a latitude and longitude.

An alternative to the new requireLatitudeLongitudeAccuracy property would be
to add a new pair of methods, getCurrentPositionV2() and watchPositionV2,
which would provide the same semantics as if this flag were present and set
to false.

Obviously the naming used here is open to discussion and any feedback is
welcome.

Thanks,
Steve

[1] http://www.w3.org/2008/geolocation/charter/charter-2
[2] http://www.w3.org/2008/geolocation/track/issues/7
[3] http://lists.w3.org/Archives/Public/public-geolocation/2009Jun/0034.html