2017.4 meeting #10 2019-05-22

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.

• 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

• #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.
    

• #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.

AOB