Annex I schema updates¶
- Annex I schema updates
On 30 April 2015, the schemas for all INSPIRE themes were updated in the INSPIRE schema repository at http://inspire.ec.europa.eu/schemas to reflect the changes have been introduced to the Annex I data models in the amendment of the Implementing Rules (Regulation (EU) no. 1253/2013) and the corresponding updated versions of the data specification Technical Guidelines.
The updates of the Annex I schemas was necessary due to the following changes in the data models and encoding guidelines.
In the amendment of the Implementing Rules and the corresponding updated versions of the data specification Technical Guidelines, a number of changes have been introduced to the Annex I data models (for details, see Annex II of Commission Regulation (EU) No 1253/2013 and the updated data specifications), namely:
- 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.
Furthermore, the encoding rules for the encoding of code lists were updated during the Annex II+III development process. According to the updated encoding rule, code list-valued properties are encoded using
gml:ReferenceType instead of
Two alternative proposals for the update were considered:
- Approach 1: Backwards-compatible update: The main goal for this approach is that, where possible, any data sets and, where possible, software that have already been created according to the current schemas (v3.x) should also be valid according to the updated schemas.
- Approach 2: Non-backwards-compatible update: The main goal for this approach is to use a methodologically clean approach for the update and to clearly communicate where there have been non-backwards-compatible changes to the data models and schemas.
Both approaches are described in detail in the attached document Alternative_approaches_Annex_I_schema_updates.pdf.
In a consultation with the MIG-T in January 2015, option 2 was unanimously preferred over option 1. However, some MS said that non backwards-compatible updates should be avoided in the future. The results of the consultation are summarised in this table.
In order to have a coherent set of schemas (including the references between them), all INSPIRE schemas (for Annexes I, II and III) had to be updated.
How long will the different versions be maintained?¶
It was agreed in the MIG-T that after April 2016, only the new versions of the schemas (i.e. v4.x for most schemas) will be maintained. This means that minor updates or bug fixes agreed by the MIG will only be made to the new schema versions.
How long can the old schemas still be used?¶
The MIG-T also discussed, for what period the usage of the old schemas is still acceptable.
Having concrete deadlines is important
- for data providers, who need to know by when to update their harmonized INSPIRE data sets to the updated schemas,
- for software vendors, who need to consider the deadlines in their release planning for their solutions (e.g. transformation tools or INSPIRE download services), and
- for developers of client applications consuming INSPIRE data, who need to know how long their application need to support the previous versions of the schemas.
For the discussion about the deadlines, different types of updates were distinguished:
- a new major version (e.g. v3.x --> v4.0), which is not backwards-compatible, i.e. existing data valid according to the older schema will no longer be valid according to the newer schema. Examples for non-backwards compatible changes include e.g. adding or removing mandatory properties or changing the types or names of existing properties;
- a new minor version (e.g. v3.0.x --> v3.1), which is backwards-compatible, i.e. existing data valid according to the older schema will remain valid also according to the newer schema. Examples for backwards compatible changes include e.g. adding optional properties to existing types or adding new types;
- a new bugfix version (e.g. v3.0 --> 3.0.1), which fixes an error in the schema. Bugfix versions are usually not backwards-compatible.
Based on feedback from MIG-T, the following time periods were agreed:
- Deprecated versions should no longer be used after 2 years after a major release
- Deprecated versions should no longer be used after 1 year after a bugfix release
- There should not be specific deadlines for minor versions, i.e. the deprecated minor version can still be used as long as the corresponding major version may be used.
This would lead to the following schema:
It should be noted that, since the schemas are not legally required, these dates can only be recommendations.
Detailed changes (Annex I schemas)¶
The table below lists the detailed changes in the Annex I xml schemas.
|Application schema||AS short name||Old schema version||New schema version||Changes|
Changes (Annex II+III schemas)¶
As explained above, also the namespaces and schema imports of Annex I schemas had to be updated in the Annex II+III schemas in order to have a coherent set of schemas (including the references between them).
Example for transforming a GML instance document to comply with the new schema version¶
This section describes what changes are required to transform an GML instance document to comply with the updated version of the ProtectedSites.xml schema.
Instance document (Ramsar_p_ps_3.0.gml) compliant with v3.0 of the Protected Sites schema (http://inspire.ec.europa.eu/schemas/ps/3.0/ProtectedSites.xsd):
<?xml version="1.0" encoding="utf-8"?> <gml:FeatureCollection gml:id="fc" xmlns:ps="urn:x-inspire:specification:gmlas:ProtectedSites:3.0" xmlns:base="urn:x-inspire:specification:gmlas:BaseTypes:3.2" xmlns:gn="urn:x-inspire:specification:gmlas:GeographicalNames:3.0" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <gml:featureMember> <ps:ProtectedSite gml:id="I1"> (...) <ps:siteDesignation> <ps:DesignationType> <ps:designationScheme codeSpace="http://inspire.ec.europa.eu/codelist/DesignationSchemeValue/">ramsar</ps:designationScheme> <ps:designation codeSpace="http://inspire.ec.europa.eu/codelist/RamsarDesignationValue/">ramsar</ps:designation> <ps:percentageUnderDesignation>100</ps:percentageUnderDesignation> </ps:DesignationType> </ps:siteDesignation> (...) </ps:ProtectedSite> </gml:featureMember> (...) </gml:FeatureCollection>
- Replace namespaces for ps, base, gn
- Add the xlink namespace (required for xlink:href references to code list values)
- Change code list encoding from using a codeSpace attribute (e.g. http://inspire.ec.europa.eu/codelist/DesignationSchemeValue/) and text value (e.g. ramsar) to a reference to the value in the INSPIRE registry (e.g. http://inspire.ec.europa.eu/codelist/DesignationSchemeValue/ramsar)
Note that, in this example, no change is required for the change of the type of element percentageUnderDesignation, since the value (100) is also valid for the new type xs:decimal. For instance document that do not already use a decimal number, the value needs to be changes as well.
Instance document (Ramsar_p_ps_4.0.gml) compliant with v4.0 of the Protected Sites schema (http://inspire.ec.europa.eu/schemas/ps/4.0/ProtectedSites.xsd):
<?xml version="1.0" encoding="utf-8"?> <gml:FeatureCollection gml:id="fc" xmlns:ps="http://inspire.ec.europa.eu/schemas/ps/4.0" xmlns:base="http://inspire.ec.europa.eu/schemas/base/3.3" xmlns:gn="http://inspire.ec.europa.eu/schemas/gn/4.0" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="http://www.w3.org/1999/xlink"> <gml:featureMember> <ps:ProtectedSite gml:id="I1"> (...) <ps:siteDesignation> <ps:DesignationType> <ps:designationScheme xlink:href="http://inspire.ec.europa.eu/codelist/DesignationSchemeValue/ramsar" /> <ps:designation xlink:href="http://inspire.ec.europa.eu/codelist/RamsarDesignationValue/ramsar" /> <ps:percentageUnderDesignation>100</ps:percentageUnderDesignation> </ps:DesignationType> </ps:siteDesignation> (...) </ps:ProtectedSite> </gml:featureMember> (...) </gml:FeatureCollection>