The INSPIRE data specifications Technical Guidelines define GML application schemas (xml schemas) as the default encoding for all INSPIRE spatial data themes. The xml schemas are made available in the INSPIRE schema repository
- endorsed schemas for data models included in the Implementing Rules
- draft schemas for extended data models included in the Technical Guidelines
Schema versions
On 30 April 2015, the schemas for all INSPIRE themes were updated to make the schemas consistent with the changes introduced in the amendment of the Implementing Rules (Commission Regulation (EU) No 1253/2013) and the corresponding Data Specification Technical Guidelines.
The Data Specification Technical Guidelines will be updated to refer to the updated versions of the schemas in the encoding section in chapter 9.
How long will the different versions be maintained?
It was agreed in the MIG-T not to insist on backwards-compatibility for this update (see the MIG-T wiki for details on the proposed approaches) and 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.
It should be noted that, since the schemas are not legally required, these dates can only be recommendations.
Category: Data Specifications
Tags: schemas