Hi all,
So over the past few days I have bitten the bullet and attempted to update to the latest version of the cite tests to deal with the issues as explained in previous discussions. Here is a status update as to where things are at.
- WFS 2.0 incompatibilities
As explained before there are a number of tests that fail due to test assumptions that wfs 1.1 is the highest version of wfs available. The newest version of the tests actually fix a lot of these issues but there are still some lingering. I am working with the cite folks to get these fixed so hopefully soon we will have all these resolved. However for some of these cases there is a bit of work that needs to be done on our part, as explained in the next section.
- Determining service version with xml namespace
In general when a request does not specify a service version the service is supposed to respond with the highest version available, as per ows version negotiation rules. However, when the request is a POST one with an xml payload we have a bit more context in order to make a better decision. And that is the xml namespace. For instance, consider this capabilities request:
<wfs:GetCapabilities service=“WFS” xmlns:wfs=“http://www.opengis.net/wfs”/>
This request doesn’t specify a version but it does specify the wfs 1.0/1.1 namespace. The wfs 2.0 request would look like:
<wfs:GetCapabilities service=“WFS” xmlns:wfs=“http://www.opengis.net/wfs/2.0”/>
So the idea here is to have the dispatcher support recognizing this and act accordingly. To do this my thought was to add a new property to org.geoserver.platform.Service called “namespace” that would correspond to the xml namespace for the service. With this the dispatcher can filter out those services that don’t match the namespace for the incoming request. Any thoughts on this? I think it seems like a sensible way to go, and actually will probably lead to a lot less headaches for client upgrading there wfs apps/clients. As long as they use the old namespace they should be safe.
I have this implemented locally and it seems to do the trick for the most part.
- 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.
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.
- srsDimension attribute on GML geometries and envelopes
The wfs 1.1 cite tests don’t use the full gml schema, only the simple feature profile of it. Which doesn’t allow for the srsDimension attribute leading to validation failures in output GML. Don’t ask me why but I think the solution here is relatively simple. When cite compliance is turned on we pass down a hint to the GML encoder to skip this attribute. Have this working locally, it was relatively straight forward.
That is about it. Looking forward to feedback.
-Justin
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.