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.
------------------------------------------------------------------------------
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
