-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
comments on the DS ATS proposal #1
Comments
Hi all, my comment is just related to share my feeling when reading this document. In order to deal with INSPIRE datasets validation issues, I spent so far some effort attempting to use the content of Annex A of Data Specifications as “the” reference. In particular, I believe that this reference is (at least right now) a good starting point to design and implement an ETS which can effectively support data providers aiming at claiming conformance of Reading the read.me document, I detect the message that I should change approach, based on several justifications provided. Therefore I feel stimulated to (re)start learning (which is always a good exercise :)), but then I start feeling a bit lost, when I see, for example, that one CC should contain both IR and TG requirements, and when I can’t find anymore any correspondence with the Annex A CCs. I would definitely need more time to better understand the reasoning of the “new” approach (due to my fault and not to the fact the read.me document is unclear :)). However, I would at least recommend creating a “mapping table” showing correspondences between the “new” tests and the CCs/tests as described in the Annex A of the DS, unless Annex A will be modified accordingly. |
I see the value in being able to distinguish the different aspects in which a spatial data set can conform to the TG. So let me try again to explain why this was not done (I tried that with the text in the readme, but obviously failed 😦): The current approach has been proposed because
Therefore, we have only a single conformance class that we can test for each application schema. If we say the last of the bullets is not important and we can split the TG conformance class into multiple conformance classes following the split in the IR conformance classes, then we could keep the following conformance classes per application schema:
"Encoding" is not in the list as this is implicitly done, partly by the common GML conformance class to which each of the "spatial data set" conformance classes has a dependency. If we follow this approach, we would need to allocate each of the current test cases to the appropriate conformance class. In some cases we may need to split a test, e.g. https://github.com/interactive-instruments/ats-spatial-data-hy/blob/master/cc-gml-hy-n/gml-hy-n.code-list-values.md partly falls under "schema" and partly under "information accessibility". So, the question is: Is it important that we keep the single TG conformance class URIs "http://inspire.ec.europa.eu/conformance-class/tg/xx/x.y(.z)" or can we introduce new ones like "http://inspire.ec.europa.eu/conformance-class/tg/xx/x.y(.z)/as", etc.? |
@gmartirano As I tried to explain there, I am not opposed to splitting up the conformance classes as done in the IR conformance classes, but as also discussed in the current ATS review an ATS in a TG has to test on the level of the TG, not the IR. Tests against the IR would always have to be manual anyhow as automated tests require selecting an implementation option. And for the TG the current TG specifies only a single conformance class and I was not sure, if we can change that. Therefore, I have included tests for IR requirements, but on TG level using the default encoding rule, in the TG conformance class. As discussed in the response to Robert's comment, if we can change that and create new TG conformance classes, then we can mostly keep the structure (some changes are necessary as sometimes there is a mix of standardization targets in a single conformance class). In any case, I agree that we need to document the mapping between the conformance classes and test cases in the current ATS in the TG and whatever approach we end up with in this activity. PS: For a more detailed reading about requirements, recommendations, conformance classes, standardization targets, etc. see the OGC specification model: https://portal.opengeospatial.org/files/?artifact_id=34762 |
@cportele to the bullet 3) Well, we can probably check some MD records on the Geoportal, but the point is that we might confuse even more some data providers with a radical change + they would loose the option of providing more grained info on the "Validation status".
What about to keep, improved if needed, the ATS and its CC structures (and individual Test cases) as neutral as possible and than have ETS with executable tests for each test case prepared for selected encodings (GML would be the first obviously)? |
@tomasrt Unless we change the definition of ATS, CC and ETS, the ETS must test exactly the requirements of the CC. But let me think about this, maybe we can use the concept of parameterizable conformance classes for this. I.e. the conformance classes can be parameterized with the encoding. For example, the conformance class AS would become AS, AS, etc. If I think this could work I will document the approach in more detail. |
I start seeing a workable solution, consisting of 1 ATS as much as possible implementation-independent and n ETS implementation-dependent, with ETS-1 related to implementation 1, with implementation 1 consisting of gml encoding, according to TGs. If this works, then I don’t see any reason to change the actual ATS as defined in the TGs. Independently from how ETS-1 will be implemented, a clear correspondence between its executable tests and the ATS CCs and related abstract tests should be provided. I tried to follow this logic reading the tests from A1.1 to A1.7 of CC-1 of HY, and it seems working to me. Of course I’m curious to see how an ETS-2 would look like, because right now I can’t figure it out :) |
I have now looked at this from two angles:
For each CC I list the test case (TC) in the structure on GitHub and also identify the section(s) in the current Hydrography TG document that this relates to:
|
I am creating an ETS for parts of this to illustrate the two options which may help in the discussion. If anyone knows some Hydro Network data encoded as INSPIRE GML that could be used for testing, this would be nice 😄. |
Hi Clemens, Maybe that can help you: http://www.ign.es/wfs-inspire/hidrografia-btn100?service=WFS http://www.ign.es/wfs-inspire/hidrografia-btn100?service=WFS&request=GetFeature&version=2.0.0&srsName=urn:ogc:def:crs:EPSG::4258&typeNames=hy-n:WatercourseLink&namespaces=xmlns(hy-n,urn%3Ax-inspire%3Aspecification%3Agmlas%3AHydroNetwork%3A3.0)&count=50 &request=GetFeature&version=2.0.0&srsName=urn:ogc:def:crs:EPSG::4258&typeNames=hy-n:WatercourseLink&namespaces=xmlns(hy-n,urn%3Ax-inspire%3Aspecification%3Agmlas%3AHydroNetwork%3A3.0)&count=50 I have also found this one http://kortforsyningen.kms.dk/hyn_elf_gml321?service=WFS http://kortforsyningen.kms.dk/hyn_elf_gml321?service=WFS&request=GetCapabilities &request=GetCapabilities Cheers, Lorena From: Clemens Portele [mailto:notifications@github.com] I am creating an ETS for parts of this to illustrate the two options which may help in the discussion. I anyone knows some Hydro Network data encoded as INSPIRE GML that could be used for testing, this would be nice 😄. — |
Thanks, @lorenahq ! |
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.
Hi all,
from the reading of the initial assumptions my understanding is that you want to create only one Conformance Class that would cover all current IR CCs also the TG CCs. Plus you will create a generic GML CC to be used by all. If my understanding is correct than I'd like to say that there were at least two reasons for having the DS ATS structured 1-7 IR CCs and TG CC as Nr. 8 (unless there are some theme specific CCs):
My question is therefore what is the benefit of having only one TG CC instead of more? Especialy if (e.g. from eENVPLus project ATS/ETS work-results) we now that it is feasible to create executable schematron scripts to facilitate automation in the most of the CCs currently in DS defined.
The text was updated successfully, but these errors were encountered: