Invalid elements in a GetFeature request to a WFS 1.1.0 server should trigger an exception

[nsavard]

Invalid elements in a GetFeature? request should trigger an 'InvalidParameterValue?' exception code.

The request is:

   URL: http://gw.mapgears.com:8500/cgi-bin/mswfs110_ogc_cite?
   Body: 
<wfs:GetFeature xmlns="http://www.occamlab.com/ctl" xmlns:ctl="http://www.occamlab.com/ctl"
                xmlns:gml="http://www.opengis.net/gml"
                xmlns:myparsers="http://teamengine.sourceforge.net/parsers"
                xmlns:ogc="http://www.opengis.net/ogc"
                xmlns:ows="http://www.opengis.net/ows"
                xmlns:p="http://teamengine.sourceforge.net/parsers"
                xmlns:parsers="http://www.occamlab.com/te/parsers"
                xmlns:saxon="http://saxon.sf.net/"
                xmlns:sf="http://cite.opengeospatial.org/gmlsf"
                xmlns:te="http://www.occamlab.com/te"
                xmlns:tec="java:com.occamlab.te.TECore"
                xmlns:wfs="http://www.opengis.net/wfs"
                xmlns:xi="http://www.w3.org/2001/XInclude"
                xmlns:xlink="http://www.w3.org/1999/xlink"
                xmlns:xs="http://www.w3.org/2001/XMLSchema"
                xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                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:Smuery srsName="urn:x-ogc:def:crs:EPSG:4326" typeName="sf:PrimitiveGeoFeature"/>
</wfs:GetFeature>

[tomkralidis]

This is going to be a tough one. We are not validating the XML in the request; I think it will be very difficult to trap errors like this without validation.

[nsavard]

Yes you're right.

[tomkralidis]

So this introduces XML validation if we want to be CITE. Right now, I believe we are using GDAL's XML parser, as opposed to libxml2? If we used libxml2, I think we can turn validation on.

I haven't used XML validation in libxml2, so I wonder whether the schemas could be cached for performance (maybe the ows_schemas_location value could be used to cache locally). Then again, this assumes using libxml2.

Assefa: comments?

[assefa]

It is a good question and don't really have a good answer to it :) :

• pros of using libxml2 is obviously the possibility to do schema validation and use a more common xml libarary.

Some notes here,

• caching the schema: yes it is possible to either use a url or a local directory to fetch the schemas using libxml2 (xmlSchemaNewParserCtxt function)

• unless we distribute the schemas of supported services with MapServer, I feel that many people won't be able to organize a local cache, so we will mostly end up using the schemas from the net.

• I have used the schema validation with tinyows and we had to add a configuration option to enable/disable validation, which we certainly need to have if we introduce this.

• Of course there is also the time to change the code to use libxml2, which won't be negligible.

At end end I think there is an advantage to have libxml2 for consistency purpose but It is always a trade off on effort vs gains in term of functionality (and in this particular OGC cite test, there are no new features for the user).

We should definitely consider it for the future but I feel at this point that efforts should be put first correcting things that do not work or are unsupported when a valid request is sent.

• I

[tomkralidis]

Replying to assefa:

It is a good question and don't really have a good answer to it :) : - pros of using libxml2 is obviously the possibility to do schema validation and use a more common xml libarary. Some notes here, - caching the schema: yes it is possible to either use a url or a local directory to fetch the schemas using libxml2 (xmlSchemaNewParserCtxt function) - unless we distribute the schemas of supported services with MapServer, I feel that many people won't be able to organize a local cache, so we will mostly end up using the schemas from the net.

Users could download  http://schemas.opengis.net/SCHEMAS_OPENGIS_NET.tgz and store locally to, say, /tmp/schemas/ (or we could have a utility to do this automagically.). Then we could introduce, say, WEB.METADATA.ows_schemas_cache "/tmp/schemas/". MapServer would then validate against the cached schema if WEB.METADATA.ows_schemas_cache exists.

- I have used the schema validation with tinyows and we had to add a configuration option to enable/disable validation, which we certainly need to have if we introduce this.

For sure

- Of course there is also the time to change the code to use libxml2, which won't be negligible.

That's an understatement :)

At end end I think there is an advantage to have libxml2 for consistency purpose but It is always a trade off on effort vs gains in term of functionality (and in this particular OGC cite test, there are no new features for the user). We should definitely consider it for the future but I feel at this point that efforts should be put first correcting things that do not work or are unsupported when a valid request is sent.

I agree no new features would result, unless you count CITE compliance as a feature. Will skipping this test not make us CITE compliant?

[assefa]

I was not aware of the schema zip. good to know. That addresses my concern on an easy access to schema files.

I think you are right that CITE compliance is a big selling feature that we should aim for, and failing one of the tests won't make us compliant for sure.I wish It was not that hard. As I mentioned, we should aim at using libmxml2 for parsing. Maybe a gradual approach, with the first thing would be converting the parsing of WFS post request and then other parts incrementally?

[nsavard]

Post request: wfs-1.1.0-Basic-GetFeature?-tc16.4

[tomkralidis]

Replying to assefa:

I was not aware of the schema zip. good to know. That addresses my concern on an easy access to schema files. I think you are right that CITE compliance is a big selling feature that we should aim for, and failing one of the tests won't make us compliant for sure.I wish It was not that hard. As I mentioned, we should aim at using libmxml2 for parsing. Maybe a gradual approach, with the first thing would be converting the parsing of WFS post request and then other parts incrementally?

Agreed. We can parse with libxml2 first, then go with validating. See mapogcsos.c which does parsing of XML POST with libxml2 as an example.

[assefa]

Add support for parsing/validating wfs post using libxml2 (r10042). It is now only available through a build flag (WFS_USE_LIBXML2). I will do more tests with CITE before making it widely available.