On 24/05/12 12:39, Justin Deoliveira wrote: > * New srs format > Currently for wfs 1.1 we use the original srs urn syntax as specified in > the original version of the wfs 1.1 spec. Which looks like: > urn:x-ogc:def:crs:EPSG:4326 > The mandated format has been changed "mid-spec" and now the tests > mandate that the format look like: > urn:ogc:def:crs:EPSG::4326 > Note the "double colon" between the authority and code, that is not a typo.
Correct. This element is for the version of the EPSG database. In general, urn:ogc versions are optional (hence the double colon), but OGC insist on their inclusion in the case of EPSG: "The “version” part shall be included in this case, since the EPSG sometimes deprecates and replaces existing definitions." From: "URNs of definitions in ogc namespace" (OGC 05-010): https://portal.opengeospatial.org/files/?artifact_id=8814 I don't like this as it is yet another point of variation to confuse clients. I am more than happy to have the version left blank, but this might cause cite compliance problems later. > So... what to do. As I see it we have a few options. > (1) Update this across the board and just output the new form by default. > (2) Only use this form when cite compliance is turned on. > (3) Add this new form as a new possibility for GMLInfo.getSrsNameStyle() > making it configurable to use the new style, updating the wfs 1.1 cite > configuration to use the newest version and possibly keeping the default > configuration using the existing style > All in all I think (3) is probably the most ideal, but represents the > most work. (1) is the easiest. Curious to here what people think about > this one. (1) may break existing clients. (2) makes we worry that some users will be stuck with all cite-compliance options when they only want one. I like (3), which is also extensible to support the new HTTP URI form (e.g. http://www.opengis.net/def/crs/EPSG/0/4326). You could also add support for an OGC URN with EPSG version (e.g. urn:ogc:def:crs:EPSG:6.3:4326). I suspect that (3) will put us in a position to add new formats almost as fast as OGC can invent them. Here are two current Jira issues: https://jira.codehaus.org/browse/GEOT-3581 https://jira.codehaus.org/browse/GEOS-4545 Support in WFS for HTTP URIs like: http://www.opengis.net/def/crs/EPSG/0/4326 is before the WFS/FES SWG and will likely be included in WFS 2.1. See: "Allow use of http URIs to identify CRS" (WFS/FES change request 11-152): https://portal.opengeospatial.org/files/?artifact_id=46445 Whitepaper: "OGC Identifiers – the case for http URIs" (OGC 10-124r1): https://portal.opengeospatial.org/files/?artifact_id=39467 HTTP URIs are current OGC policy: "In June 2010 OGC revised the naming policy to use http URIs to identify persistent OGC resources instead of URNs." http://www.opengeospatial.org/projects/groups/ogcnasc Youse might also be interested in Simon's recent seminar on controlled vocabularies (slides and audio): https://wiki.csiro.au/display/ARRCSeminars/Delivering+controlled+vocabularies+on+the+web+-+persistent+identifiers+and+the+web+of+things Simon explains why HTTP URIs are useful because they allow the implementation of Tim Berners-Lee's Linked (Open) Data rules, and describes some successful patterns for using them. Kind regards, -- Ben Caradoc-Davies <[email protected]> Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
