>Ted Hardie wrote, on 2009-06-02 12:52:
>
>
>>As long as the other datum can be named in a parameter, there are no surprises;
>>if you see a triple with a named datum in that parameter, you use that datum
>>to understand the reference. Else, you use the default--WGS84.
>>
>>Is it simple? In the case where WGS84 is in use, yep it is as simple as the
>>geo URI as currently described. It is also more extensible--with the URI
>>syntax giving you the ability to get that extensibility while giving you
>>a useful default.
>>
>>
>The problem with this is that usually when an implementation doesn't understand
>a URI parameter, it will just ignore it and parse the rest of the URI and use it
>as if the parameter wasn't there. In these cases the content would parse as a
>WGS84 location but would be wrong.
>
>And I predict that most implementations of the "geo" URI will ignore the
>parameter and assume WGS84, given that the parameter will very rarely be present.
>
>
I tend to agree with Ted. IMHO, it would be better if extensibility can
be added to the geo URIs now, before they are widely deployed.
Experience with mailto: URIs suggests that it is much more painful
adding extensibility after the fact.
>This is an interoperability trap.
>
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
