OGC Testbed-14: Compliance Engineering Report

The WFS3 work aims at building a complete test suite for WFS3 core and output format extensions. WFS3 brings a set of novelties influencing the test development in a number of ways:

The security client work is important enough to merit its own Engineering Report, which can be found at D003 Secure Client Engineering Report.

The CSW compliance aims at having a metadata catalog compliant with the DGIWG Metadata Foundation (a profile of the ISO19115/ISO19139 standard); the catalog shall be able to:

The previous Compliance Interoperability & Testing Evaluation (CITE) tests did not have the machinery to deal with a resource oriented service and its peculiarity, the new tests for WFS 3.0 thus set a valuable reference for future tests.

The CSW compliance activity did not share the same novelty, but was instrumental in reviewing the DGIWG CAT specification and providing feedback for it, as well as validating the ability to implement in an actual server and test it with a compliance suite.

The reference implementations for WFS 3.0 also enjoyed new test coverage which resulted in a number of improvements for increased compatibility and interoperability.

The current setup of the specification and tests imply that a server can be certified compliant only if it implements the GeoJSON extension, however at the same time, the specification core mandates no output format implementation. This could be addressed by the specification mandating the GeoJSON format, making the test suite more useful and making it easier to write generic clients at the same time.

Failing that, the WFS 3.0 test suite should try to support as many output formats as possible, in particular, the GML profiles. The HTML output format would be harder to verify instead, as there is no indication of its contents, the test suite would be left verifying links between pages without meaningful access to the data.

Security plays an important part of data dissemination, however, the current test suite only addresses open, un-secured, servers. It would be useful to get future extensions understanding OpenAPI security declaration, being able to gather credentials at the start of the test, and thus being able to issue authenticated requests against a secured server.

Finally, it is to be noted that both tests and reference implementations for WFS 3.0 are based on a draft of the specification, and might need to be adjusted according to changes that might occur in the final WFS 3.0 release.

All questions regarding this document should be directed to the editor or the contributors:

Contacts

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

The WFS 3.0 CITE tests are currently testing a single requirement class, the "core" one.

In order for core to be testable, the OpenAPI and GeoJSON conformance classes also need to be implemented. They are not fully tested themselves, rather they are leveraged to test the core one (by being used in the tests, they get partially covered as well).

All Hypertext Transfer Protocol (HTTP) requests sent by the test suite follow the REST concept. Nevertheless, any HTTP client can be used to send the requests as REST, using the HTTP protocol.

The test suites requires the /api resource as an OpenAPI document. Thus, a parser that is capable of processing those responses is needed.

As the test suite is written in TestNG, any Java HTTP client (for HTTP requests) and any Java parser (for HTTP responses) can be used for the executable tests.

The following libraries/frameworks can be used to make creation of tests easier and readability better:

All options regarding the Java HTTP client were evaluated closely. Finally, the decision fell on REST-assured, as this framework also offers other useful functionalities (besides a Java HTTP client) which are not provided by Jersey and Spring RestTemplate.

The main functionality added by REST-assured is the capability of validating REST services with Java. As this is the main focus of a test suite, it was clear that REST-assured was the framework best fitting the needs at hand.

Regarding the HTTP responses a parser is needed that provides OpenAPI documents parsing support. As KaiZen-OpenAPI-Parser is currently the only OpenAPI parser, it was decided to use this library.

The implementation of the test suite is kept as close as possible to the Abstract Test Suite defined in the specification.

First, the Core conformance class is implemented by creating one or more tests (Java methods) per abstract test defined in specification. The description of each implemented test references the corresponding test of the Abstract Test Suite and the requirement which is verified by that executable test.

The optional conformance classes, HTML, GeoJSON, GML Simple Feature Level 0 (SF-0) and GML SF-2 are not part of the test suite. The reason of this decision is that these conformance classes are not covered by the Abstract Test Suite of the specification.

Instead, the implementation work concentrated on creating a stable and robust executable test suite of the Core conformance class.

Also, the test suites have two important preconditions: the JSON encoding and OpenAPI interface must be supported.

This section covers noteworthy issues that needed to be handled during the test development.

The server provides data from direct data sources and implements the following requirement classes:

The server also offers a number of experimental extensions that include:

The CubeWerx D113 deliverables consist of servers deployed at the following endpoints:

This deliverable consists of a single component, a WFS 3.0 server implementation developed by GeoSolutions as a community plugin to the GeoServer open source software.

The source code of the plugin has been made available to the GeoServer community, from the start, through the public GitHub repository, while its binary form can be found among the nightly builds of the development series.

The plugin can be installed by simply un-packing the contents of the zip file in the GeoServer WEB-INF/lib directory and re-starting GeoServer.

This component is published as four separate endpoints, exposing the OSM data for Daraa and Zaatari areas, both as unsecured and secured services:

The server provides data from direct data sources and implements the following requirement classes:

The deliverable consists of two components, a WFS 2.0 component and a WFS 3.0 component that is a facade providing access to the WFS 2.0 services.

The ldproxy tool has been developed as a proxy for WFS endpoints to explore how WFS could be better aligned with today’s Web and the expectations of developers and users. See, for example, the report "Spatial Data on the Web using the current SDI" from the Geonovum tested in 2016. The results have been input to the development of the W3C/OGC Spatial Data on the Web Best Practice and the OGC Change Request for WFS 3.0.

The WFS 3.0 landing pages are:

The server serves data from direct data sources and implements the following requirement classes:

The server also offers the following experimental extensions:

The tests verify compliance for the following conformance classes:

The implementation of the test suite is kept as close as possible to the ATS defined in specification.

First, the DGIWG_Basic_CSW conformance class is implemented by creating several tests (Java methods) per abstract test defined in the specification (this is necessary as there are just three abstract tests being too complex to become only three executable test). The description of each implemented test references the corresponding test of the ATS and the requirement which is verified by that executable test.

After having completed the implementation of the DGIWG_Basic_CSW conformance class, the DGIWG_CSWT conformance class is implemented. Again, there are just two abstract tests which are too complex for only two executable tests. Thus, there are more than two executable tests. The description is populated as described above.

The final release covers all conformance classes defined by specification, DGIWG_Basic_CSW and DGIWG_CSWT.

The major challenge found during implementation is related to inaccuracies found in the ATS itself. For example, references are missing and there are contradictory requirements. All inaccuracies have been documented in GitHub issues.

The schema plugin has been implemented following the step described in the implementation guide referenced above; since the guide is a bit old, also some adjustments have been done in order to comply with the requirements needed in the latest versions.

The implementation followed the requirements described in this document. The DGIWG 2.0.0 schema files needed for GeoNetwork are available at this link. They have been slightly edited in order to simplify the directory hierarchy.

While the Testbed only required schema compliance, a GUI for editing DGIWG metadata has been implemented in order to ease creation of DGIWG compliant metadata. Some examples follow.

In order to satisfy all of the requirements of the "Defence Profile of OGC Catalogue Service for the Web 2.0" GeoNetwork needed some configuration to be done outside the schema plugin. All of the related information is reported in the documentation files of the DGIWG metadata plugin.