[...]
>>> However, there are a couple of advantages to the current approach:
>>> 1. Abstraction: You can use "wgs84" to represent both the 2D and 3D
>>> CRSes, depending on whether altitude is present
>> ... at the expense of having to maintain a separate registry of such
>> labels, and a mapping of these labels to URIs.
> The reality is that the key requirement here is that everyone
> understands what the labels mean, whether they are short-form labels
> or URIs.
Yes.
> URI matching is a lot trickier than label matching (since it can be
> some form of string compare). You can limit the URI type to
> something like a URN (which will avoid some of the
> many-strings-dereference-the-same-resource problem of HTTP),
It may make sense, but I don't think that such limitation is
really necessary. The specification may RECOMMEND for the CRS
URIs to be restricted to a particular set of URNs.
To be honest, what I've had in mind suggesting crsURI= is
certainly the `urn:ogc:def:crs:EPSG:*' URNs.
> but those essentially are pointers to a registry entry, with the NID
> telling you *which* registry.
The point is not to have /no/ registry at all, but to have no
/extra/ registry just for the geo: URIs.
> I'm personally fine with that way forward, but I hope if we go down
> that road we strongly indicate which NIDs are likely.
No objections on that.
[...]
--
FSF associate member #7257
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
