Serving society Stimulating innovation Supporting legislation 5. Annex I schema updates Michael Lutz

Changes to Annex I data models in IR Some candidate types and placeholders and the references to them have been removed (since they have been replaced by other types in the Annex II+III themes). Some candidate types and placeholders have been re- included in the Physical Waters package in the Hydrography theme Some references have been updated to types in Annex II+III themes Some additional sub-types of HydroObject have been created in the Sea Regions theme An additional data model has been developed for Maritime Units. One minor change of a geometry type (from GM_Surface to GM_MultiSurface) has been made in the candidate type Shore.

Principles for updating the schemas Goal: data sets created with old version of the schema should remain valid also according to the new version Create new versions: 3.0  3.1 Keep namespaces (in order to guarantee backwards compatibility)  alternative: state that all data will remain valid if only the namespace is changed Deprecate & make optional rather than delete elements

Comments Clemens Portele Impact on software based on the current schemas  how will changes be implemented in software packages? Expectation seems to be that all software packages will be updated (in some reasonable amount of time) to the new version  to avoid software based on the old version reporting unexpected errors for instances that make use of the changes. Need for outreach and coordination with those that develop or operate software for INSPIRE (similar to the replacement of the OGC Xlink schema by the W3C Xlink schema) Need to be careful with such revisions as they cost money and resources to implement, but do not always provide any benefit to most or even all stakeholders

Comments Clemens Portele Recommend to consider not updating the schemas right now, but that the MIG first develops a strategy / plan for revisions of the INSPIRE schemas and communicates this to the stakeholders first Balance the need from a legal point of view to adjust the schemas to the amended IR and required additional efforts from implementers/operators. Revision strategy should consider implementing and demonstrating any proposed changes first and evaluating their value before a new revision is approved. Such schema changes also touch the topic of "compliance" that should be addressed in a revision strategy, too. If the new schema replaces the old schema, or if a new revision deprecates a precursor, when will data (and thus implementations) supporting the old schema be considered no longer compliant?

Comments Ilkka Rinne Many problems with the INSPIRE schemas result from the fact that not very many organizations have actually been implementing systems using schemas. Only when the schemas go through enough real-world use we can expect not to find too many design errors and typos in them. The problem of course is that organizations producing INSPIRE data would like to get the official (final is probably too expecting too much) INSPIRE schemas before they do the implementation work. Thus only a little practical experience is gained before the models and schemas are made "official".

Comments Ilkka Rinne MIG should establish a development and release process for INSPIRE models and corresponding schema files (similar to what many open source software products have done) The process should describe  how changes are accepted to the models/schemas,  how those changes are tested and evaluated before merging the changes form "development" branch to the "master" branch,  how the model/schema versioning is done,  when the older versions will be deprecated,  which changes qualify as corrigenda,  how all this activity is communicated and the changes rolled out to the public.

Comments Sylvain Grellet Postpone the public update? Strategy is needed because  stakeholders will feel that it is better to wait rather than act  compliance will soon start to be really messy between the commercial speech  people will have to claim to be “Inspire version X.Y.Z compatible Should some kind of INSPIRE conformity label be set up (with model versions in the process) be set up ? Are we sure Annexes II & III xsds are stable enough for the coming months? How can we take benefit of European projects (reportings, FPx, …) experience to identify beforehand as many possible issues as possible?

Proposed way forward Immediately create sub-group on schema management  aims: define strategy for schema updates (by end of February), propose Annex I updates and release plan  Schedule: ? Publish Annex II+III schemas as soon as possible  What further tests could be performed before publication? Inform INSPIRE community about the issues and plans around the schema updates