Briefing and Planning meeting on INSPIRE validator implementation – Discussion 16/12/2015

Note on styling  Bold means “must have”  Normal style means “should have”, “could have” or “nice to have”

Use Cases  Potential actors / responsibilities  Data and Service Provider (related to implementation obligations)  Geoportal (for metadata)  National coordinator  Data user  Solution provider  EC  Test developer  Tool software provider  MIG-T member  Main goal is to help data and service providers, not to police them  Data and Service Provider – Relevant aspects  Control what I want to test  Select ETS (specific version), CC  more fine grained?  For specific deadlines?  Control where I want to test  Central deployment  In my own environment  Process results  Get informed about the test progress / results in useful way  Publish / share test report (that could be liked from metadata, websites, etc.)  Potentially in Discovery Service or text for copying to the discovery service  Find history of my test results  Use the tests in my production and publication workflow (API, scripting)  Add additional tests (for extensions, profiles)  Who had similar issues?  Who can access test results?

INSPIRE Testing Framework – Requirements  Architecture  Document model of ATS, ETS, test objects, test results, etc.  Use Ilkka’s model as a starting point  Need to support different types of tests, potentially with different components  Data tests (XML potentially very large)  Metadata tests (XML, smaller, could be together with the Network Service tests)  Network service tests (Web Service)  General conformance  QoS  Open question what this means (in terms of testing)  Need to distinguish test project scope  Tests based on the test object alone (“validation test”)  Tests involving referenced resources (“interoperability test”)  needs to be reflected in ATS / CC  The framework should be based on a generic test engine that can process executable tests specified in one or more ETS languages/formats  It should be possible to update or add rules without needing to recompile, rebuild or redeploy the test engine  It should be possible to interact with the test engine through a GUI and through an API  Reuse existing ETSs  Multilingual support

INSPIRE Testing Framework – Requirements  Test objects  Consolidation of existing multiple tests or on not yet existing tests  Check with Member States?  The testing framework should (at least) accept single requests to test the conformity of  a metadata record  a network service endpoint  View  Download 1  Download 2  Download 3  Discovery  a data set  Annex I (lack of existing tests, 2017 deadline)  Theme 1  Theme 2  Theme n  Annex II/III  a spatial data service endpoint  The framework should support the testing of large data sets (e.g. orthoimagery)

INSPIRE Testing Framework – Requirements  Test results  The test engine shall return a detailed test report in human-readable (e.g. HTML) or machine- readable format (e.g. XML, JSON)  Multilingual support (not multi-lingual ETSs)  Timestamp  Sharing and publishing – see use case slide  Notification via (if errors)  Scheduling (see GDI-DE)  User dashboard  User configured “test run templates”  Direct access to “my” test results (dashboard)  Require registration to be discussed at later stage (maybe for data sets or certain sizes?)

INSPIRE Testing Framework – Requirements  Test projects and their management (discuss again in January telecon)  The ETS language/format should allow easy modification of rules and documentation of a version history  It should be possible to select / define modules at individual rule level (rule=test)  It should be possible to test against specific versions of the rule  It should be possible to validate against specific schema versions (this may require parameterisable rules) – versions of ETSs (based on version of the CC/TG as well as of the ETS), older ETS versions are available, but deprecated  It should be possible to indicate the severity or weight of individual rules  Requirement  error  Recommendation  warning  ETS rules should have links to the ATS rules they implement and requirements they test  Licensing  The test engine and ETS languages/formats should be open source

INSPIRE Testing Framework  Identify how the MIWP-5 team could best support the development  Discuss in January web-meeting