Serving society Stimulating innovation Supporting legislation Proposal for a new MIWP action on GML-related aspects Michael Lutz MIG-T meeting, Rome, 1-3 December 2015

The issue(s) Gap between the (complex) INSPIRE xml schemas and what current client tools (web and desktop) can consume  xml schema complexity reflects complexity of conceptual UML models (because of automatic generation according to the normative UML-to-GML encoding in D2.7 Encoding Guidelines)  Most existing clients (e.g. GDAL/OGR OS library) consumes and writes flat data structures INSPIRE data encoded according to the current schemas can be downloaded and viewed, but it can often not be used directly in other tools in order to do further analysis or processing Possible solutions 1.reducing complexity of the schemas for data exchange 2.encouraging better support by vendors

1. Simplification of xml schemas Proposals exist and are already implemented in tools (e.g. ShapeChange) Conceptual modelImplementation model Type-A att-A1 Type-B att-B1 att-B2 att-A2 Type-C att-C1 att-C2 prop-A3 link-to-D Type-D … Type-A att-A1.B1 att-A1.B2.1 att-A1.B2.2 att-A2.C1 att-A2.C2 prop-A3 link-to-D Type-D … UML-to-XML rules (D2.7) simplification rules But currently no agreed way on how to create simplified schemas that would still meet the requirements of the IRs Should be driven by theme-specific requirements, but also consider cross-cutting aspects (e.g. how to flatten recurring complex structures such as geographical names)

1. Out of scope: Simplification of conceptual model Simplification of / changes to the conceptual model is out-of-scope for the proposed action If there is a need for such simplification, this should be discussed in MIWP- 14 and the Thematic Clusters Conceptual modelUpdated conceptual model Type-A att-A1 Type-B att-B1 att-B2 att-A2 Type-C att-C1 att-C2 prop-A3 link-to-D Type-D … UML-to-XML rules (D2.7) simplification of conceptual model Type-A att-A1 Type-B att-B1 att-B2 att-A2 Type-C att-C1 att-C2 prop-A3 link-to-D Type-D …

2. Better client support for complex GML Some vendors and projects have also already started to improve the support for GML However, different projects/vendors implement different (arbitrary subsets) of GML/XML Analysis of the subset of XML schema (and GML) that is required in INSPIRE and for specific INSPIRE themes is currently missing

3. xml schema change management Additional issue already described in MIWP-18a Changes in the xml schemas can impact on implementation of software Develop a development and release process for updating and maintaining XML schemas (incl. communication, versioning, corrigenda, who is doing the review, etc.) Coordinate with software developers and data providers about proposed changes to ensure implications of changes are kept to a minimum, that people are informed and plans made about how to migrate. Include here or keep separate?  Links to (1) and (2)

Proposed actions 1.In collaboration with thematic communities (through the Thematic Clusters platform and MIWP-14 sub-group), investigate use cases and requirements for simplified schemas. Based on these requirements and a set of possible schema simplification rules, develop proposals for simplified schemas and corresponding documentation that explains how (and/or under which conditions) the proposed encoding meets the requirements of the IRs 2.Analyse which GML/XML schema aspects are actually being used in INSPIRE schemas and discuss with the open source community and commercial vendors how support for the needed GML/XML schema aspects can be better supported in client software 3.Define a formal process for management and updates of XML schemas

1. Simplification of xml schemas Through the TC platform and MIWP-14 sub-group, investigate use cases & requirements for simplified schemas Create a repository of possible simplification rules to be applied (based on existing material from MS or projects) Document for each simplification rule how (or under which conditions) the proposed encoding meets the requirements of the IRs (to be included in D2.7) Based on domain-specific use cases and user needs, propose additional simplified schemas for selected application schemas to the MIG for review and endorsement Investigate how the simplification and the mapping from the conceptual to the implementation model should be explicityly represented in UML / Enterprise Architect

2. Better client support for complex GML Analyse which GML/XML schema aspects are actually being used in INSPIRE schemas, e.g. which themes use only SF, level 0 or which geometry types are used Analyse support for the required aspects are supported in existing clients, including the popular GDAL/OGR open source library (that is underlying most OS and proprietary client solutions) Discuss with the open source community and commercial vendors, how to improve client support for GML

3. xml schema change management Define a formal process for management and updates of XML schemas Define how to communicate changes, e.g. what does deprecation mean, what does it mean to be based on an older version Define procedure for testing, review and endorsement, including the need to involve different kinds of producers (& larger community) Develop proposal for reflecting changes (e.g. deprecation) also explicitly in the UML model, so that UML models, diagrams and schemas are kept in sync. and updated schemas could also be generated automatically Also be clearer of what “removing” attributes/classes mean – how much longer are they still valid?

Outcomes (Tasks) Repository of possible simplification rules (1) Proposals for an update of D2.7 Encoding Guidelines (1) Proposals for additional simplified schemas for selected application schemas (1) Table of GML/XML schema aspects actually being used in INSPIRE schemas (2) Process for management and updates of XML schemas (3)

Organisational set-up Form a MIG sub-group Some of the tasks will be carried out by a contractor A pilot project will be set up for gathering requirements and testing the proposed simplification rules Open questions  Given current experience with the MIG sub-groups, what should be its role and which tasks should be out-sourced?  Should the whole action be carried out as part of a pilot?  How to involve vendors and users?

Comments received – EEA Discussing new schemas may slow down DS implementation (that is only just starting) Focus instead on better tool support Ensure that tools have to be able to work with extended schemas flattened schemas can already be used now (suggested schemas are not legally binding) Using a mixture of complex and simple GML could cause interoperability issues

Comments received – France We have no users for the full INSPIRE data models  need to flatten data models to deliver datasets to public authorities Need a common approach across Europe, in particular for Annex I+II themes and for reporting data Flattened data models should be based on specific use cases Clarify what “compliance with the IRs” means. E.g. the lack of multiplicities in the IRs could open an opportunity for simplification No need to work on tools, specially if ARE3NA does the job We need maybe to be smarter with the models to be able to produce them in Annex I & II, where data producers are national organisations, and share these data in the simplest way for users, without hoping change their tools

Comments received – UK Endorse the idea of simplification INSPIRE stalls at this stage, because some of the things we’re pushing for cannot be used Preference for getting the stuff that can be simple to work, in order to prove the value