joanma747
commented
4 years ago So the change was intentional and we were acting to comply to the new policy: https://docs.opengeospatial.org/pol/09-046r5.html#_historical_note_on_urns_and_urls_informative
WMTS doesn't reference 2D-TMS so in principle should not affect old implementacions.
BUT
There is a policy in OGC that is quite mature that not just sets the preference for URIs but also explains how to convert URNs in URIs. This policy does not overrule WMTS because it had no retroactive effects. So, any implementation of WMTS 1.0 should still support URNs only.
The OGC NA will still support URN references for the WMTS 1.0 and introduces HTTP URIs for the 2D-TMS objects.
So the change was intentional and we were acting to comply to the new policy.
No chagnes in the URI approach will be done.
Action for the editor. Include a coment on the URN in WMTS and a reference on how to transform them to URIs. https://docs.opengeospatial.org/pol/09-046r5.html#_naming_rule. Implement a on-the-fly translations is possible based on these rules.
I just noticed that the well-known-scale-set URIs have changed between WMS 1.0 (OGC 07-057r7) and OGC 17-083r2. In the former it's "urn:ogc:def:wkss:OGC:1.0:GoogleMapsCompatible", while in the latter it's "http://www.opengis.net/def/wkss/OGC/1.0/GoogleMapsCompatible". Was this change made intentionally? Which are WMTS servers now supposed to report? Do client applications now need to check for both forms? This issue, and how to deal with it, needs to be addressed.
In the future, we aught to be more careful about changing well-known identifiers like this just to adapt to the flavour-of-the-month. It wreaks havoc with interoperability.