Date: Wednesday, 22 May 2019, 15:00-16:30 CET

Web conference


[15:00-15:10] Welcome, approval of the agenda & minutes of the previous meeting

[15:10-15:20] Status update on development of the Reference Validator

[15:20-16:00] Open Github issues for 2017.4 discussion, in particular:

[16:00-16:15] Workshop on the ETF Validator (#20)

[16:15-16:30] AOB


Discussion items & actions

ItemNotes / Actions
Welcome, approval of the agenda & minutes of the previous meeting

Agenda and minutes of previous meeting approved. All the open actions will be discussed later in the meeting, except the following:

  • issue #146: making INSPIRE localID unique can be a nice extension, and it is agreed to discuss this possible extension of the ETS in the workshop (see below).
  • About the work on data-service linking under the 2019.2 MIWP Action, a tool named Resource Linkage Verification Tool (currenty in beta version) was developed to allow checking the linkages between MD and View/Download services and returning a report with the issues in the verification process. A work is ongoing with 11 MS which are preparing test MD; results of the test will be reported in the MIG meeting in June.
Status update on development of the Reference Validator
  • There are currently 3 instances of the Reference Validator:
    • production instance (deployed by the JRC): will be dismissed as soon as the new cloud production instance is ready (beginning of June, see the release planning notes).
    • cloud production instance (deployed on AWS): at the moment it is simply a copy of the JRC instance; it is usable but still under testing (horizontal scaling).
      • new ETS on MD TG v. 2.0, View Services (WMS & WMTS) will be added at the beginning of June; ETS on Download Services (WCS & SOS) will be added in mid-June (see the release planning notes);
    • staging production instance (deployed on AWS): includes the latest developments of the Validator, i.e.
      • new ETS on MD TG v. 2.0, View Services (WMS & WMTS), Download Services (WCS & SOS); Discovery Services (CSW) will be added at the beginning of June (see the release planning notes).
        • MIG-T representatives were invited to contact their national providers asking for testing; experts in SOS and WCS were also asked to test and provide feedback.
      • new functionality: display of conformance class dependencies (see issue #6)
  • Issue tracker:
    • users willing to report an issue in the ets-repository repo are now directed to the community repo (see the new issue template).
    • labels are applied to categorize issues:
      • issues for which a solution will be developed: under analysis, planned, under development, ready for testing, solved, deployed in reference validator
      • other issues: question, discussion, for-2017.4-discussion, wontfix
Open Github issues for 2017.4 discussion
  • #39 View Service WMS validator too strict: harmonized layer names should not be mandatory
    • Following the comment from Michael, it is agreed to have 2 conformance classes, in order to: 1) relax the requirement for View Services, i.e. only check that a Layer Name element is provided; 2) implement a requirement that checks for the harmonization of layer names, in accordance to the IR on ISDSS.
    • Contractors to modify the test, accordingly.
  • #42 WFS Pre-defined: validation of StoredQuery fails on a recommendation
    • it is agreed to relax the test as described in Michael's comment, i.e.: if there is no stored query with the recommended id, or if there is no stored query with all the required parameters, make it a manual check (check that there is only one possible combination of the required parameter(s) involved).
    • later, we can have a discussion with the MIG-T on whether the TG should be also rephrased.
    • Contractors to modify the test, accordingly.
  • #43 View Service WMS: Fees element is mandatory when external service metadata is provided
    • Thijs is correct that the Fees element should not be checked since we are in scenario 1.
    • Although the ATS is correct, the ETS seems to be wrong, because it starts from the hypothesis of scenario 1 and, if at least one element among those listed is found, assumes we are in scenario 2 (see lines 57-70). Conversely, the ETS should assume to be in scenario 2 and check whether there is an <inspire_common:MetadataURL> element: if yes, then we are in scenario 1.
    • Contractors to modify the test, accordingly.
  • #44 View Service WMS: Capabilities XML schema validation fails with SLD operations
    • There is a general agreement that the Validator should allow extensions, i.e. other schemas in addition to those required by INSPIRE.
    • If we change the behaviour to validate against all the schemas declared, this might generate problems (e.g. there might be local schemas only available on the intranet).
    • Another option is to only allow some well-known WMS extensions, like SLD.
    • It is agreed to keep the discussion open, waiting for some more examples from other countries.
    • all to provide examples related to their countries.
  • #45 Validation of metadata document of ISO 19115 profile (SeaDataNet profile)
    • #183: solved
    • #184: we keep the discussion open on whether the test should be relaxed (to allow not only gco:CharacterString or gmx:Anchor as child elements of the Code element)
    • #185: solved
  • #46 Validation error for TM_Period <gml:endPosition indeterminatePosition="unknown"/>
    • It is agreed that, if the value of the `indeterminatePosition` attribute is `unknown `or `now`, the test should not check the presence of the empty value.
    • Contractors to modify the test, accordingly.
  • #47 Adding further info into TestRun result log
    • It is agreed to keep the discussion open in GitHub and discuss the topic during the ETF workshop.
  • #52 Validation error on LanguageCode
    • A solution might be to check whether the code list mandated in Requirement C.5 has been used; if not, a manual check can be implemented, which asks user to check whether the code list used is a manual extension of that code list.
    • Alternatively, there can be directly a manual test, which simply asks to make sure that the code list used is a valid code list.
    • JRC to look for a possible solution, understanding how much effort this requires; otherwise, we can relax the test and modify the TG.
    • Contractors to change the test, to allow also for the code list http://www.loc.gov/standards/iso639-2 (without the final /) to be accepted
  • #53 Example of a fully-compliant MD TG v. 2.0
    • It is decided to share the 2 MD records (for datasets and for services) as separate files on GitHub, and manage the review process as follows:
      • for mistakes or concrete proposals for change, make the changes directly in the file and submit a Pull Request.
      • for generic comments, use the discussion in the issue.
    • all to provide comments until the end of next week (June 2), after which it will be finalized according to the feedback received and published on the INSPIRE Knowledge Base.
    • JRC to make also the MD for services available on GitHub.
  • #4 ETF Status page
    • all to provide comments.
Workshop on the ETF Validator
  • #20 Workshop on the ETF validator
    • Feedback on the workshop was provided: some countries are more interested to have a user-focused, some other to have a developer-focused.
    • JRC to come up with a draft agenda, for a 2-day workshop in September.

    • JRC to start collecting nominations of people to attend as well as additional topics or suggestions.


The date of next meeting will be communicated by JRC, based on the activity in the helpdesk.