search

opengeospatial / ets-wfs20

Executable Test Suite for WFS 2.0
Other
9 stars 11 forks source link

Test fails at Preconditions - dataAreAvailable #219

Closed lukastemberga closed 2 years ago

lukastemberga commented 2 years ago

Hi all! I'm having problems validating wfs service against validator. I'm trying to validate this service. But validation fails at Preconditions - dataAreAvailable. With error java.lang.AssertionError: Prerequisite not satisfied: No valid data available from WFS.

From my understanding validator sends a GET request to: https://dev.li-st.net/geoserver/am1/ows?service=WFS&version=2.0.0&request=GetFeature&count=25&typenames=ns44:AM.RiverBasinDistrict&namespaces=xmlns(xml,http://www.w3.org/XML/1998/namespace),xmlns(ns44,http://inspire.ec.europa.eu/schemas/am/4.0),xmlns(wfs,http://www.opengis.net/wfs/2.0)

And server responds with error:

Unknown namespace []

I know this wfs does indeed serve data, as I can pass DataSet test at INSPIRE validator, but on Download services test I get this response.

If I change parameter namespaces to namespace server responds, but I don't think that is the issue. I would very much appreciate if you could give me some advice on how to fix this issue. Thanks in advance!

Steps to reproduce the behavior:

  1. Go to https://cite.opengeospatial.org/teamengine/test.jsp
  2. Test with https://dev.li-st.net/geoserver/am1/ows?service=wfs&version=2.0.2&request=GetCapabilities
  3. Fail test at preconditions with described error
dstenger commented 2 years ago

Thank you for reporting.

I realized that requesting https://dev.li-st.net/geoserver/am1/ows?service=WFS&version=2.0.0&request=GetFeature&count=25&typenames=ns44:AM.RiverBasinDistrict returns a valid response.

Thus, the namespaces (spelling is correct) parameter causes the error. I would assume this is an error on the server side as the syntax also looks fine. Can you please check if the namespaces parameter can be processed by the service in general?

lukastemberga commented 2 years ago

Thanks for your answer!

I can't seem to get any response without the mentioned error when using parameter namespaces. What ever the argument and in whatever form yields the same error. Is it possible that this parameter isn't properly (or at all) implemented in GeoServer WFS? I can't seem to find any documentation on it.

Looking at this document, it seems this parameter is not mandatory. So would an acceptable solution be to query the data without using namespaces?

Thank you very much for your answers!

dstenger commented 2 years ago

You are right that "namespaces" is an optional parameter and when taking a look at the abstract test suite this parameter is not mentioned.

So, typenames parameter can be used without namespaces parameter (also see chapter 7.9.2.4.1 typeNames parameter).

Table 7 — Additional common keywords for KVP encoded WFS requests says about NAMESPACES parameter:

Used to specify namespaces and their prefixes. The format shall be xmlns(prefix,escaped_url) where escaped_url is defined in (see OGC 06-121r3:2009, 11.3). If the prefix is not specified then the default namespace shall be assumed. More that one namespace may be bound by specifying a comma separated list of xmlns() values.

This parameter is not defined for XML encoded requests because XML has another mechanism for asserting namespaces (see 6.3).

I am not quite sure how the default namespace is defined in this case.

We will discuss in the OGC CITE Team if the usage of parameter namespaces can be removed from the test.

dstenger commented 2 years ago

@lukastemberga If we considered namespaces as an optional parameter, the service should ignore it if not implemented. E.g.:

However, in the 2nd case an error is thrown which means that the parameter is evaluated by the service leading to an unexpected error.

If we send the following, a valid response is returned: https://dev.li-st.net/geoserver/am1/ows?service=WFS&version=2.0.0&request=GetFeature&count=25&typenames=am1:AM.RiverBasinDistrict&namespaces=xmlns(am1,http://inspire.ec.europa.eu/schemas/am/4.0)

Thus, the parameter just works if prefixes are used which are already defined by the service. As the namespaces parameter should enable using custom prefixes, the implementation in the service seems erroneous.

In conclusion, we would expect the service to ignore a not implemented parameter and not to evaluate it erroneously.

Thus, we do not consider this as an error in the test suite. Can you please re-check your implementation? If you have any further questions, you are welcome to contact us via this issue.

lukastemberga commented 2 years ago

Thank you for your answer and for reviewing this issue. It does indeed seem like this is a problem with configuration of GeoServer. I will try to discuss the issue further on GeoServer mailing list. I think this issue can be closed now if you agree. Sincerely, Luka