Test passing by accident on the new WFS 1.1 test suite
------------------------------------------------------
Key: GEOS-2065
URL: http://jira.codehaus.org/browse/GEOS-2065
Project: GeoServer
Issue Type: Bug
Components: WFS
Affects Versions: 1.7.0-beta1
Reporter: Andrea Aime
Assignee: Andrea Aime
Priority: Critical
Fix For: 1.7.0
The test wfs:wfs-1.1.0-Basic-GetFeature-tc14.1 states:
{panel}
The geometry representations in the response must correspond to the CRS specified in the @srsName attribute, or the service default if not specified or unknown. Use values as recommended in OGC 06-023 (e.g. 'urn:x-ogc:def:crs:EPSG:6.10.2:4326').
{panel}
and the request is:
{code:xml}
<wfs:GetFeature xmlns="http://www.occamlab.com/ctl" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:ctl="http://www.occamlab.com/ctl"
xmlns:saxon="http://saxon.sf.net/"
xmlns:parsers="http://www.occamlab.com/te/parsers"
xmlns:te="java:com.occamlab.te.TECore"
xmlns:sf="http://cite.opengeospatial.org/gmlsf"
xmlns:ogc="http://www.opengis.net/ogc"
xmlns:wfs="http://www.opengis.net/wfs"
xmlns:p="http://teamengine.sourceforge.net/parsers"
xmlns:ows="http://www.opengis.net/ows"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:gml="http://www.opengis.net/gml"
xmlns:myparsers="http://teamengine.sourceforge.net/parsers"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
service="WFS"
version="1.1.0">
<wfs:Query srsName="urn:x-ogc:def:crs:EPSG:4326" typeName="sf:PrimitiveGeoFeature"/>
</wfs:GetFeature>
{code}
When the patches for GEOS-2064 are applied, this test stops passing because we end up answering
wit urn:x-ogc:def:crs:EPSG:6.11.2:4326 instead of using urn:x-ogc:def:crs:EPSG:4326.
If the CITE really means we have to answer with the same exact urn used in the request, we're not compliant
even without the patches, the test just passes because our hard coded answer matches the test expectation,
for example, if the test used the suggested value 'urn:x-ogc:def:crs:EPSG:6.10.2:4326' we would not pass it
either way.
The test is in my opinion broken, as it cannot expect the server to respond with the same verbatim urn,
but just by an equivalent one. Failing a fix for the test, we could work around by providing a context value
to the encoder that specifies the expected srs encoding, or enable, just when the cite hacks are on, a
simple text post processing filter that replaces all occurrences of our urn encoding with the one used
in the request (should they differ). The latter really qualifies as a "cite hack" 
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira