- 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