-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
To address the discussion in #1, the ATS and the conformance classes have been revised completely. To illustrate and test the approach, ETSs have been developed for some of the conformance classes. A small sample test data set has been accessed from an INSPIRE download service and tested against the ETSs. The resulting test report is also added.
- Loading branch information
Showing
69 changed files
with
68,789 additions
and
1,646 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,47 +1,57 @@ | ||
| # Abstract Test Suite for the Data Specification on Hydrography | ||
|
|
||
| Abstract Test Suite for the Data Specification on Hydrography – Technical Guidelines (version 3.1) and the associated GML application schemas (version 4.0.0) specifying requirements for the interoperability of spatial data sets of the data theme hydrography. | ||
| Abstract Test Suite for the Data Specification on Hydrography – Technical Guidelines (version 3.1) and the associated GML application schemas (versions 3.0 and 4.0) specifying requirements for the interoperability of spatial data sets of the data theme hydrography. | ||
|
|
||
| *Note*: This ATS is under development, none of the tests have an official INSPIRE MIG approval. | ||
|
|
||
| ## Relationship with the Abstract Test Suite in the document | ||
| ## Approach | ||
|
|
||
| The Technical Guidelines document contains IR requirements (quoting text from the regulation) and additional TG requirements. This is the basis for an Abstract Test Suite contained in the document as Annex A. The following summarizes the current structure: | ||
| We have used the following approach: | ||
|
|
||
| 1. The implementation-independent requirements are specified in regulation 1089/2010 (including its amendments). | ||
| 1. There is one GML conformance class per application schema with non-abstract spatial object types. This is basically the "encoding schema validation test" from the TG conformance class in the data specifications. | ||
|
|
||
| 2. The data specification for each theme includes the general requirements from the regulation ("IR requirements"). These copy the regulation text and are only partly tailored to the specific theme or application schema context. | ||
| 2. In order to make the IR conformance classes testable, they are understood as parameterized conformance classes with the encoding rule as the parameter. Note: The concept of parameterized conformance classes is described in the [OGC Specification Model](https://portal.opengeospatial.org/files/?artifact_id=34762). | ||
|
|
||
| 3. These IR requirements are then grouped in the ATS of the data specification into several conformance classes. Dependencies between the conformance classes are not identified, so they are all independent of each other. The test cases do not reference the IR requirements in the document directly, but it is safe to assume that these will match. | ||
| 3. All XPath expressions in the IR conformance classes are based on the default GML encoding rule. I.e., the current versions of the IR conformance classes are parametrized with the default GML encoding rule and have an indirect dependency to the GML application schema conformance class. | ||
|
|
||
| 4. As the IR requirements are implementation-independent, the test cases for them cannot be tested in an automated way and require manual inspection or questions to the data provider. | ||
| 4. As a result, there is no need for an encoding-related IR conformance class. Instead, the details how to test the conformance for any additional encoding rule would need to be added to the relevant tests and a new conformance class for the validation against the schemas would be added. | ||
|
|
||
| 5. In addition to the IR requirements, each data specification also includes TG requirements. These are all bundled into a single conformance class per application schema without any dependency to any of the other conformance classes. The test cases do not reference the TG requirements, but sections of the TG document. | ||
| 5. The IR conformance classes for application schemas without non-abstract feature types, e.g. "Hydrography - Core", are not needed as no feature instance can be of a type from that application schema. | ||
|
|
||
| 6. As these conformance classes are used to declare conformance in the spatial data set metadata, they probably have to be used as they are (including their URIs). | ||
| 6. All generic tests related to the GML encoding rule are moved to a new INSPIRE GML conformance class (that should become part of D2.7 in a future revision) and which all other TG conformance classes would normatively reference / depend on. | ||
|
|
||
| 7. Several of the requirements have a different standardisation target (i.e. not the spatial data set). Some of the requirements are on the spatial data set metadata or on the view service operating on the spatial data set. | ||
| 7. The conformance classes with a different standardization target are not included for now. Only the requirements on a data set resource are included. | ||
|
|
||
| This is an issue as strictly we can only develop an Executable Test Suite with automated tests for the TG conformance classes. This testing would result in quite incomplete tests, in particular as the majority of the TG test cases are not for the spatial data set, but are for the metadata or the view service, and therefore need to be part of a separate conformance class anyhow. I.e. there would mainly be tests for XML schema validation and CRS URIs. | ||
| Note that the TG conformance class is "informative" in the data specification documents. This is not appropriate, there is no such thing as an informative requirement. For a TG, which the data specifications are, the TG requirements are normative and so should be the TG conformance classes. | ||
|
|
||
| This would not be a satisfactory result. | ||
| ## Conformance classes | ||
|
|
||
| In order to proceed towards a more satisfactory solution, the following interpretation is used: | ||
| The following conformance classes related to the spatial data set have been identified as a result: | ||
|
|
||
| 1. Every data specification will only have a single (tested) conformance class per application schema with instantiable spatial object types with the spatial data set as the standardization target. This is basically the TG conformance class, with the changes described below. | ||
| * [Conformance class "INSPIRE GML encoding rule 3.3"](inspire-gml/README.md) | ||
| * [Conformance class "GML application schema, Hydrography - Network 3.0/4.0"](gml-hy-n/README.md) | ||
| * [Conformance class "Application schema, Hydrography - Network 3.1"](hy-n-as/README.md) | ||
| * [Conformance class "Reference Systems, Hydrography - Network 3.1"](hy-n-rs/README.md) | ||
| * [Conformance class "Data Consistency, Hydrography - Network 3.1"](hy-n-dc/README.md) | ||
| * [Conformance class "Information Accessibility, Hydrography - Network 3.1"](hy-n-ia/README.md) | ||
| * Conformance class "GML application schema, Hydrography - Physical Waters 3.0/4.0" | ||
| * Conformance class "Application schema, Hydrography - Physical Waters 3.1" | ||
| * Conformance class "Reference Systems, Hydrography - Physical Waters 3.1" | ||
| * Conformance class "Data Consistency, Hydrography - Physical Waters 3.1" | ||
| * Conformance class "Information Accessibility, Hydrography - Physical Waters 3.1" | ||
|
|
||
| 2. The TG conformance class is restructured to include tests for all IR requirements and TG requirements that have the spatial data set as the standardization target. The IR requirements are tested under the assumption that the (mandatory) default encoding is used, i.e. in general the GML encoding. Where this is not possible, there will be a manual test. | ||
| The conformance class 'INSPIRE GML encoding rule 3.3' is only temporary in this Abstract Test Suite and belongs to its own Abstract Test Suite for the 'Guidelines for the encoding of spatial data' document. | ||
|
|
||
| 3. We remove the metadata and view service requirements from the TG conformance class and create new conformance classes for those standardization targets. Again, the requriements would be tested under the assumption that ISO/TS 19139 is used (for the metadata) and that WMS 1.3.0 is used (for the view service). | ||
| The conformance classes related to the 'Physical Waters' schema have not been created yet, but they would follow the same pattern as the network schema tests. | ||
|
|
||
| 4. We move all generic GML tests into a new INSPIRE GML conformance class (that should become part of D2.7 in a future revision) and which all other TG conformance classes would normatively reference / depend on. | ||
| The conformance class regarding the metadata for interoperability is currently documented in a [separate ATS](https://github.com/inspire-eu-validation/ats-interoperability-metadata). Note that the MIWP-5 work has created a single conformance class, independent of the application schema, while each data specification currently specifies a separate conformance class. | ||
|
|
||
| The TG conformance class is always "informative" in the data specification documents. This is not appropriate, there is no such thing as an informative requirement. For a TG, which the data specifications are, the TG requirements are normative and so should be the TG conformance classes. | ||
| The conformance class regarding the view service portrayal still has to be created. | ||
|
|
||
| ## Conformance classes | ||
| ## Example | ||
|
|
||
| To illustrate and test the approach, draft XQuery-based executable test suites have been created for the conformance classes documented in this ATS. The test suites have been created using ETF as the framework and BaseX as the test engine. This has some limitations with respect to the support for the domain model specified in the current design report (version 0.3) as ETF does not yet support all aspects. For example, 'manual tests' have been classified as a 'warning' as ETF currently does not support this concept. The test project with the definitions of the executable test suites is **[hy-n-assertions.xml](hy-n-assertions.xml)**. | ||
|
|
||
| * [INSPIRE GML encoding of spatial objects](cc-gml/README.md) | ||
| * [GML encoding of application schema 'Hydro - Network', version 4.0](cc-gml-hy-n/README.md) | ||
| * [GML encoding of application schema 'Hydro - Physical Waters', version 4.0](cc-gml-hy-p/README.md) | ||
| A **[small test data set](data/README.md)** has been accessed from an INSPIRE download service. | ||
|
|
||
| The conformance class 'INSPIRE GML encoding of spatial objects' is only temporary in this Abstract Test Suite and will be moved to its own Abstract Test Suite for the 'Guidelines for the encoding of spatial data' document. | ||
| Using the executable test suites and the sample test data set, a **[test report](wfs-es-hy-n-result.html)** for the test of this sample data set against the conformance classes has been created. |
Oops, something went wrong.