9th MIWP-5 sub-group meeting (ATS comment resolution)

Friday, 15 April 2016, 9:30-12:30 CEST

Connection details

Recording: MP4, AdobeConnect player

Agenda

[9:30-9:45] Status of the comment resolution process

  • Issues that have not yet been processed
  • Other problems encountered

[9:45-12:15] Comments that require further discussion 

[12:15-12:30] Next steps

Minutes

Actions are highlighted with the keyword [Action] below.

Main conclusions

  • Issues which require a change to the TGs will be split up into two types
    1. vague requirement in the TG -> document the interpretation in the issue on GitHub, these can be taken into account in future TG updates
    2. technical changes to the TG -> reject the resolution and follow the standard TG update process through the MIG
    • The label type:TGCR should be used for (2) TG change request, so that they can be easily extracted from the Github repository.
  • Flag issues related to consistency constraints of the infrastructure using the label type:X-Component-Consistency 
  • A new ATS will be created for v2.0 of the TG MD. As a result, the current ATS work should only focus on v1.3
  • Regarding the usage of terminology, the following was agreed:        
    • Requirements Class: collection of related requirements within a specification (to be decided whether or not it will be used or just conformance class)
    • Test Case: abstract or executable definition a test method to validation conformance to one or more requirements
    • Conformance Class: collection of Test Cases covering one or more Requirements Classes
    • Abstract/Executable Test Suite: collection of all Conformance Classes of a specification or a distinct part of it

Next steps

  • [Action] Each assignee to update issues based on today's discussion
  • Continue discussions directly on GitHub
  • Focus on Metadata, Download Services in light of the ETS implementation
  • Follow-up call between 26 and 29 April to discuss remaining issues that are open-for discussion on download services and metadata

Attendees

Clemens Portele, Freddy Fierens, Jens Scheerlinck, Marcus Sen, Markus Seifert, Paul van Genuchten, Stefania Morrone, Thijs Brentjens, Peter Parslow, Michael Lutz, Ilkka Rinne, Antonio Rotundo, Daniel Cocanu, Daniela Hogrebe, Angelo Quaglia, James Passmore

Summary of discussions and conclusions

References to ATS-issues:

General issues encountered during the review process

  • Misunderstanding with Alejandra (ES) concerning the call for helping with the resolution. She instead provided additional comments.
    • Issues assigned to Alejandra will be taken on by the JRC, as there were no volunteers apart from PwC  (who raised the issues, thus input from some other party would be required)

Cross-cutting issues

  • X-8: Agreed on approach to add error messages to the ATS as the ETS are being developed.
    • Approach: don't update ATS directly but use ATS maintenance process (e.g. create issue to propose change) -> no immediate action required
  • Atom-52: This specific issue involves a relatively small change of specifying draft 5 in the TG.
    • For now, usage of draft 5 will be fixed in the ATS. Clarification in TG need during next revision -> flag as TG change
  • WMS-114: Consistency with regard to referenced CRS will have to be ensured across TGs -> flag as TG change
  • General comment related to issues which require a TG change: An approach was agreed on how to deal with issues that require a change to the TG. 
    • Divide issues into one of two types:
      1. vague requirement in the TG -> document the interpretation in the issue on GitHub, these can be taken into account in future TG updates
      2. technical changes to the TG -> reject the proposed change in the resolution and follow the standard TG update process through the MIG
    • Use the label type:TGCR for (2) TG change request, so that they can be easily extracted from the Github repository.
  • MD-98: In general, do not test if there is no requirement. Regarding ISO19139, a change request will be made to v1.3 of the TG MD to include these requirements. Lastly, dependencies regarding base standards will be added as prerequisites to test cases.
  • DIS-9 & WMS-127: Conformance to third-party specifications on ATS level will only be expressed as a reference to the relevant conformance class(es). Nevertheless INSPIRE will continue to require conformance with the referenced third-party standards. Deciding which ETSs to use for this will be decided during the implementation of the ETSs. We will not develop our own ETSs for third-party specifications but instead rely on passing external ETSs (e.g. OGC CITE tests) where available or rely on self-declaration.
  • General comment regarding v1.3 and v2.0 of the TG MD: A new ATS will be created for v2.0 of the TG. As a result, the current ATS work should only focus on v1.3 of the TG.
    • [Action] JRC to organise a discussion with MIWP-8 on the creation of a new ATS based on TG 2.0 (in parallel to the on-going MIG-T consultation)
    • To be decided what is the best solution for creating versions of ATSs in GitHub (branch or copy).
  • Atom-67: Known issues with certain software packages could be added as a note in the test case.
    • If software (here Internet Explorer) is deemed important enough to warrant a change in requirements, this should be done through a TG change request.
  • X-15 & X-5: Agreed on proposal to alter the composition/structure of ATSs according to conformance classes.
    • [Action] Clemens Portele to make a concrete proposal.
  • General comment regarding the use of terminology: agreement with e-mails sent by Clemens and Ilkka on 15/04:
    • Requirements Class: collection of related requirements within a specification (to be decided whether or not it will be used or just conformance class)
    • Test Case: abstract or executable definition a test method to validation conformance to one or more requirements
    • Conformance Class: collection of Test Cases covering one or more Requirements Classes
    • Abstract/Executable Test Suite: collection of all Conformance Classes of a specification or a distinct part of it.

Cross component consistency issues

  • MD-55 & others:
    • In general, stick to the standardisation target in the ATSs
    • Include tests only where consistency is required in the TG
      • Consistency checks should be included for the standardisation target, where a possible inconsistency would matter most to users (and where this is more easily testable). E.g. if the CRS documented in the metadata is not the one actually used in a data set, this inconsistency will be more relevant when trying to use/access the data set than when trying to use/access the metadata.
    • Document consistency constraints of the infrastructure in one place
      • Flag issues with the label type:X-Component-Consistency 
      • Collect all such consistency constraints in a single document, which should serve as the basis for the discussion on how to deal with them in the long run
    • Note: Currently only some consistency checks in the Geoportal validator, but no resolution for conflicting file identifiers (as an example)

WMS/WMTS related issues

  • WMS-108: divided into (1) consistency issues and (2) does TG MD or TG WMS state a requirement concerning this consistency? -> flag as consistency check and TG issue
  • WMS-110:
    • Namespace: in general we will have to live with this, it just something that we inherit from the ISO standard
      • may create issues for many, has impact
      • continue discussion on GitHub
      • should be resolved by TG -> formulate issue on TG level and flag as TG change request
    • Non-INSPIRE layers: separate issue -> requires TG update (flag as such)
       
  • X-4: Agreed on proposed resolution, only applies to group layers with name
  • WMTS-34: common tests will be kept separate for now, but consider factoring out a common conformance class in future TG updates
    • Tools that help with requirements management could help here (Polarion was mentioned)
    • Angelo finds the current GitHub approach verbose and difficult to get an overview.
    • A change to a requirements management tool would impact all INSPIRE specifications and MIG activities.
    • [Action] JRC to discuss with PwC/ii possibilities to investigate this tool issue further.

Metadata related issues

  • MD-15 & MD-115: both on TG version -> comments referring to the new version of TG will be rejected and a change request formulated to the TG
  • MD-95 & MD-29: based on the current MD TG it is impossible to test, because there is no clear requirement. As this is rather a gaping hole, this should be clarified based on a change request to V1.3 of the TG.
    • Proposal: create consistent set of schemas (using GitHub) for JRC to host
      • pro: clear solution
      • con: yet another schema in the srv namespace and endorsement from all Member States required.
    • Proposal to create new namespace deemed problematic because current srv namespace is already referenced by many metadata records
    • [Action] Peter Parslow will take this issue forward