PreDefined WFS validation uses outputFormat=application/json in DescribFeatureType request

[thijsbrentjens]

• a description of the steps to reproduce your issue

1. Use the validator: Conformance Class: Download Service - Pre-defined WFS
2. Test URL: https://geodata.nationaalgeoregister.nl/natura2000/wfs?service=WFS&version=2.0.0&request=GetCapabilities, run this test
3. The test fails on the initialization, Autoconfigure WFS, for the 2nd Get Schema Definition (Failed)
   The test reports that in a DescribeFeatureType request the outputformat = application/json is used. But the WFS does not advertize this for DescribeFeatureType. It seems a bug in the test itself.

• the browser and version used
  Firefox (but does not seem relevant)

• the Test Report (ideally as an attachment to the issue)
  Report: http://inspire-sandbox.jrc.ec.europa.eu/etf-webapp//v2/TestRuns/EID94ba1848-9eaa-4cde-8d07-205fb577f0df.html?lang=en
  Logfile: http://inspire-sandbox.jrc.ec.europa.eu/etf-webapp//v2/TestRuns/94ba1848-9eaa-4cde-8d07-205fb577f0df/log

• the name of the Test that failed or better: change the Level of Detail
  in the Report by clicking on All Details, then scroll down to the failed test
  and copy the Link on the right-hand side of the Assertion URI

Autoconfigure WFS > Analyze WFS Capabilities >Get Schema Definition (2nd)

http://inspire-sandbox.jrc.ec.europa.eu/etf-webapp//v2/TestRuns/EID94ba1848-9eaa-4cde-8d07-205fb577f0df.html?lang=en#EID7b9b01f4-0169-1000-8858-6ec45ca35ebe

-[x] the URL of your service / the file you have uploaded or referenced (as
an attachment).
Example: https://geodata.nationaalgeoregister.nl/natura2000/wfs?service=WFS&version=2.0.0&request=GetCapabilities

[inakidiazdecerio]

Dear @thijsbrentjens,

Thanks for reporting the issue. Checking the service GetCapabilities looks like there is a bug in the validator, the test is checking the wrong output format. We will come back to you with the solution.

Best regards,

Iñaki

[thijsbrentjens]

Dear @inakidiazdecerio , thanks, it would be great if a solution would come. This bug is blocking the use of the validator to test on the Predefined requirements, at least for some WFS implementations. So if you have an idea when a solution might come, please let it know.

[inakidiazdecerio]

Dear @thijsbrentjens, we understand your concern. We want to let you know that we are looking for a solution for this issue, is not an easy one. So we will need a little bit more time for developing the solution and test it. Sorry for the inconvenience and thank you for your patience.

[josemasensio]

Dear @thijsbrentjens,

We have been looking at the bug and it looks like we are moving forward with it.

For now we are still investigating.
We hope to have the solution soon.

Best regards.

[thijsbrentjens]

Hi all, this issue is open now for a long time. Because this issue is a blocking issue for some of the services in the Netherlands to use the validator, could you please confirm it will be fixed in the next release? We would really like to promote the validator in the Netherlands

[carlospzurita]

Dear @thijsbrentjens

We are still working on this issue for now. It is a rather complex issue caused by a bug in the TestStep setup for "Analyze WFS Capabilities", because it is selecting the wrong parameters for the DescribeFeatureType operation, even though the initialization of outputFormats is correct and is getting the correct values from the XML response.

We are trying to solve this issue for the next milestone. Whenever we have more feedback to offer, we will get back to you.

Kind regards.

[thijsbrentjens]

thanks for the update :)

[iuriemaxim]

@thijsbrentjens @carlospzurita

I do not think that the problem is in the validator, but in the GetCapabilities document

1. Remove application/json subtype=geojson from GetCapabilities document. This media type is not defined by IANA
   Correct media type for geojson would be according to https://www.iana.org/assignments/media-types/application/geo+json
   Full list here: https://www.iana.org/assignments/media-types/media-types.xhtml
   There is no such media type as "application/json subtype=geojson"

Indeed the text shown by the validator is not correct, but actually refers to the fact that the application/json subtybe=json should not be used within the GetCapabilities document:

2. Not sure if the OutputFormat should be here, but I think that due to this the validator is indicating an error related to DescribeFeature. First try to remove the "application/json subtype=geojson" that is not correct according to IANA. If it will not work, then remove the entire section (as it is also redundant with the GetFeature operation).

This is how another WFS Get Capabilities that validates against the same test look like (https://inspire.meteoromania.ro/WIGOS/WFS?service=WFS&request=GetCapabilities)

@thijsbrentjens Hope it helps.

@carlospzurita I think this can be marked as discussion, for future reference.

[thijsbrentjens]

@iuriemaxim thanks for thinking along. But I disagree, this issue can not be closed.

The outputFormat application/json; subtype=geojson in the Capabilities document is advertized for a GetFeature request, but the issue is that the format is used for DescribeFeatureType and that is an issue of the validator. The Capabilities do not advertize that format (https://geodata.nationaalgeoregister.nl/natura2000/wfs?service=WFS&version=2.0.0&request=GetCapabilities) for DescribeFeatureType:

<ows:Operation name="DescribeFeatureType">
<ows:DCP>
<ows:HTTP>
<ows:Get xlink:type="simple" xlink:href="https://geodata.nationaalgeoregister.nl/natura2000/wfs?SERVICE=WFS&language=eng&"/>
<ows:Post xlink:type="simple" xlink:href="https://geodata.nationaalgeoregister.nl/natura2000/wfs?SERVICE=WFS&language=eng&"/>
</ows:HTTP>
</ows:DCP>
<ows:Parameter name="outputFormat">
<ows:AllowedValues>
<ows:Value>application/gml+xml; version=3.2</ows:Value>
<ows:Value>text/xml; subtype=gml/3.2.1</ows:Value>
<ows:Value>text/xml; subtype=gml/3.1.1</ows:Value>
<ows:Value>text/xml; subtype=gml/2.1.2</ows:Value>
</ows:AllowedValues>
</ows:Parameter>
</ows:Operation>

The fact that the mediatype is not defined by IANA does not matter. There is no restriction there in WFS 2.0.

[iuriemaxim]

@thijsbrentjens Try to correct the media type and see if it validates. The validator indicates clearly that the application/json subtype=geojson is not supported.
If the media type is not defined in IANA how can a tool provide support for it?
How can a tool guess that the "application/json subtype=geojson" is application/geo+json
Same is valid for the following wrong names of the media types

[iuriemaxim]

@thijsbrentjens it is not true that there is no restriction in WFS 2.0 and that any custom media types can be used.

WFS 2.0. indicates that the responses should be encoded according to OGC 06-121r3:2009.

And in the OGC 06-121r3:2009 standard it is mentioned:

[iuriemaxim]

I also indicated that most probably the validator gets confused and indicates an error related to GetFeature request because of the following elements that are present in the FeatureTypeList element and are not expected to be present at this location. And in FeatureTypeList are specified the media types of the features, (used by GetFeature). There is also present the same media type that is not accepted, namely application/json subtype=geojson. I mentioned that you specified media types of the features in two places (in FeatureTypeList element and when describing the DescribeFeatureType operation) and in and this is not ok as well.

So first remove application/json subtype=geojson from here, or better remove the entire content encircled in red, as the media types of the features are declared in the DescribeFeatureType, as correctly indicated in the post above (there the application/json subtype=geojson is not advertised).

[iuriemaxim]

@carlospzurita Indeed the validator can indicate more clearly for those unsupported media types, that "Only IANA MIME types can be included in GetCapabilities document according to section 11.7.3 of the OGC 06-121r3:2009"

[thijsbrentjens]

I still think that for DescribeFeatureType the validator should never ask for a JSON format. Because it is not advertized by the server.

Only for GetFeatureType it is advertized. That should not block running a validation session.

So @carlospzurita : because it is scheduled for the v2021.0 milestone, can I safely communicate to dataproviders that a fix will come for this issue?

[iuriemaxim]

@thijsbrentjens As I explained above the validator finds the JSON declared as a format during the GetCapabilities operation.

The GetCapabilities document should be fixed and the JSON should be advertised correctly according to IANA with the correct MIME format.

If the validator will be changed,, then most probably the validator will just provide a different error. But still the implementation has errors, is just that the validator gets confused.

[copierrj]

All our services support GeoJSON as output format in order to facilitate easy access from a typical browser environment. Removing GeoJSON support would therefore inconvenience our users and we are at the moment not prepared to do that.

As far as we understand relevant standards it is actually allowed to support additional output formats besides the ones mandated by the OGC standard and the INSPIRE technical guidance.

Obviously it makes little sense to perform a DescribeFeatureType requests with GeoJSON as output format as such a request is nonsensical. Our service capabilities document correctly reflects this by omitting GeoJSON as allowed output format for this request type.

The validator currently (in our opinion incorrectly) performs a DescribeFeatureType for GeoJSON anyways. A solution could be to have the validator perform DescribeFeatureType only for a fixed set of output types (i.e. the formats mandated by the specifications) or at the very least only for the formats actually advertised in the capabilities.

[iuriemaxim]

@copierrj That not a problem to advertise that the service supports GeoJSON. As I explained above there are services that support GeoJSON as output and are passing the Validation tests. The two GetCapabilities documents can be compared.

https://inspire-staging.meteoromania.ro/WIGOS/WFS?service=WFS&request=GetCapabilities

&

https://geodata.nationaalgeoregister.nl/natura2000/wfs?service=WFS&version=2.0.0&request=GetCapabilities

In the mentioned service, the error is within the GetCapabilities document. But indeed the validator throws a misleading error. In any case it should throw an error as the GetCapabilities document is incorrect and inconsistent. I do not know what exactly the validator does or what it can do, but the service listed above is not correct as I already explained.

So what can be analised in the GetCapabilities document of the service in question is why the Validator is triggering that error. For sure on the other service it does not trigger that error, so it does not perform a DescribeFeatureType requests with GeoJSON, even if the service advertise that it supports GeoJSON. I just thik then that the error is in the GetCapabilities document declarations where there are inconsistencies and errors. And due to those inconsistencies the validator is trihhering a misleading error. But the reason of the misleading is the GetCapabilities document that is misleading. So if someone is misleading the other can provide a misleading response.

[JLSchaap]

@carlospzurita can we expect a improvement for v2021.0 milestone on this issue?

[iuriemaxim]

@JLSchaap Do you have a correctly configured service to test?

The https://inspire-staging.meteoromania.ro/WIGOS/WFS?service=WFS&request=GetCapabilities service supports GEOJSON and no error is triggered, as the service and the GetCapabilities document are correctly configured.

If the service is not correctly configured in relation to GEOJSON output format, then an error is triggered.
Indded the error triggered by the validator is not correctly indicating where is the issue in the service https://geodata.nationaalgeoregister.nl/natura2000/wfs?service=WFS&version=2.0.0&request=GetCapabilities

So an improvment in the validator will still trigger an error to the above mentioned service, just that the text could be more clear to indicate to the user where the problem is located.

[JLSchaap]

Thanks @iuriemaxim, I understand that the answers is no on my question.

[carlospzurita]

Dear @JLSchaap

We did not have advances on this issue for the 2021.0 milestone, we are scheduling it for the next release. Sorry for the inconveniences.

[JLSchaap]

Thanks @carlospzurita for the information, we are looking forward to see the improvements on this issue .

[JLSchaap]

Hello @carlospzurita, Can you explain why this issue is removed from the milestone. Thanks in advance.

[iuriemaxim]

@JLSchaap Probabbly if it will be fixed, just the error message will be different. But most probably the validator will stil provide an error.

Alternatively the incident can be marked as "usertofix".

[arbakker]

The OGC WFS spec is quite clear on the role of the FeatureType/OutputFormats element (section 8.3.4 FeatureTypeList):

OutputFormats: The wfs:OutputFormats element shall be a list of MIME types indicating the output formats that may be generated for a feature type. If this optional element is not specified, then all the result formats listed for the GetFeature operation are assumed to be supported.

Which states the FeatureType/OutputFormats elements maps to the OutputFormats of the GetFeature operation. IMO the validator should respect the spec by only using the OutputFormats of the DescribeFeatureType operation for the DescribeFeatureType operation. Thus this issue should not be marked as usertofix.

[KadasterJongerius]

Helllo @jenriquesoriano can you please inform us about the status of this issue?

[JLSchaap]

I see that this issue is "under development", Can we expect this issue is fixed before november 2022?

[JohannaOtt]

@fabiovinci Any idea on when there will be a related change so that the validator will stop requesting DescribeFeatureType as GeoJSON?

[fabiovinci]

Dear @JohannaOtt,

do you have a sample WFS that we can use to reproduce the error?

[mwjsanders]

@fabiovinci
To be able to make progress with this ticket, jou can use the WFS endpiont: https://service.pdok.nl/rws/digitaaltopografischbestand/wfs/v1_0?ACCEPTVERSIONS=2.0.0&request=GetCapabilities&service=WFS&VERSION=2.0.0

In the capabilities of this service the DescribeFeature is advertised to able to output a description in xml/gml:

<ows:Operation name="DescribeFeatureType">
<ows:DCP>
<ows:HTTP>
<ows:Get xlink:type="simple" xlink:href="https://service.pdok.nl/rws/digitaaltopografischbestand/wfs/v1_0?"/>
</ows:HTTP>
</ows:DCP>
<ows:Parameter name="outputFormat">
<ows:AllowedValues>
<ows:Value>application/gml+xml; version=3.2</ows:Value>
<ows:Value>text/xml; subtype=gml/3.2.1</ows:Value>
<ows:Value>text/xml; subtype=gml/3.1.1</ows:Value>
</ows:AllowedValues>
</ows:Parameter>
</ows:Operation>
<ows:Operation name="GetFeature">

but when testing this service using the reference validator, the Featuretype description is requested in application/json subtype=geojson although this is not advertised

see validation report: https://inspire.ec.europa.eu/validator/test-run/details.html?id=EIDed3e0ebf-f7dc-4655-bf3c-52c5547b18c5