Details
Description
On WFS output, the schema locations encoded on the header are describeFeatureType URL for that type eg.
<wfs:FeatureCollection
...
xsi:schemaLocation="urn:cgi:xmlns:CGI:GeoSciML:2.0 http://d00109:8082/geoserver-ws-0.1/wfs?service=WFS&version=1.1.0&request=DescribeFeatureType&typeName=gsml:MappedFeature
http://www.opengis.net/wfs http://d00109:8082/geoserver-ws-0.1/schemas/wfs/1.1.0/wfs.xsd">
Users have been complaining that these schema locations wouldn't validate on XML editors (in particular XMLSpy), stopping them from doing further work.
Users can now supply schemaLocation in their app-schema mapping file eg.
<targetTypes>
<FeatureType>
<schemaUri>http://schemas.opengis.net/GeoSciML/geosciml.xsd</schemaUri>
</FeatureType>
</targetTypes>
The patch I attached fixes the schema location to encode to the provided schema URI, if there is one. Otherwise it'll encode the describeFeatureType URL by default.
Test covered in updated FeatureChainingWFSTest as well.
On the side note, the WFS schema location relates back to the host and that if the application is deployed on a separate machine, they won't be able to access the schema, eg.
"http://d00109:8082/geoserver-ws-0.1/schemas/wfs/1.1.0/wfs.xsd"
But I'm going to raise a different issue for that one and address it later.
If we specify the schema, we should not create redundant info in the mapping file for the location. Schema location and namespaces should be extracted from the schema. (so kill the namespace mappings too). The patch could be seen as a workaround, pending the ability to read the schema details properly - so put a comment at least into mapping files that use it.