- From: Richard Barnes <rbarnes@bbn.com>
- Date: Fri, 27 Feb 2009 13:36:29 -0500
- To: Alec Berntson <alecb@windows.microsoft.com>
- CC: "public-geolocation@w3.org" <public-geolocation@w3.org>
Hi Alec,
Thanks for bringing this issue back up. My $.02:
> a. I propose we use the same fields as the CivicAddressReport in
> the Windows 7 Location API.
Where on earth did you get that idea? :)
I tend to agree with Allan that a representation compatible with RFC
4119 (more properly, RFC 5139) would be more universally applicable.
I appreciate that some view this as too complex, so there may be value
in producing a simplified version. However, it should be a profile of
the IETF format, in that there should be a 1-1 mapping between the two.
> b. I propose: Enum {CoordinatesOnly, CivicAddressOnly, Either}
The IETF HELD protocol [1] has a similar option. The way HELD solves it
is to specify a list of acceptable formats, then a boolean "exact"
option to specify that exactly that set must be provided. In this case,
you would define an Enum {coordinates, civicAddress, any} for location
formats, then have an array of these plus a boolean. (An empty array
signifying [any], exact=false)
These two approaches are equivalent when you have the two location
formats (civic & geo), but the second (HELD) approach scales better when
there's more than two (e.g., if you allow location to be provided by
reference).
--Richard
[1] <http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery>
Received on Friday, 27 February 2009 18:37:09 UTC