Re: Civic Address for V2

Hi Richard,

On Tue, Mar 3, 2009 at 12:08 AM, Richard Barnes <rbarnes@bbn.com> wrote:
> Hi Andrei,
>
> <trimmed>
>>
>> What I don't understand is why do
>> you say that it should be a profile of the IETF format. I'm not aware
>> of any such requirement.
>
> The reason to do this is to minimize translation to and from the IETF format
> when location travels from one to the other.  It could do this in two ways,
> as an input and as an output.
>

I understand this goal. However, I feel that this isn't as important
for our spec as providing a format that is easy to understand and code
against. As I mentioned in the email to Marc, we could provide an
appendix that shows how to convert to / from the IETF format. This
would be as a convenience to those Geolocation API implementers who
may have to deal with the IETF format as an input (or an output for
those specific usecases you mentioned). The users of the Geolocation
API should be offered something simpler.


>
>> Also, if it's a simplified format, how can we
>> have a 1-1 mapping to the full format? To me simplified means somewhat
>> less fields, right?
>
> You can have a 1-1 mapping with fewer fields by combining fields according
> to a well-defined algorithm.  For instance, the Austrian registry of civic
> addresses has many more fields then even RFC 5139 defines, but there's a
> well-defined translation between the two defined in a GEOPRIV document:
> <http://tools.ietf.org/html/draft-ietf-geopriv-civic-address-recommendations-02>
>

Yep, this is what could go into the Appendix.

> It doesn't necessarily have to map the full format, but in that case, you
> have to accept that you lose information when you translate into the W3C
> format (and might want to note this in the spec).
>

Agreed.

All the best,
Andrei

Received on Tuesday, 3 March 2009 15:11:08 UTC