Serving society Stimulating innovation Supporting legislation Alternative approaches for Annex I schema updates Michael Lutz MIG-T meeting, 27/11/2014

Option 1: backwards-compatible update Currently proposed approach Goal: existing data implementations stay valid also with the new schema Schema version: minor update – 3.0  3.1 Namespace: same as before Schemas are relaxed, e.g.  removed elements are deprecated and made optional  new code list encoding is implemented using “union” type between gml:CodeType and gml:ReferenceType Client software needs to be adapted to accept the relaxed schemas  e.g. accept data without the newly optional elements

Option 2: new major version Goal: Clearly communicate changes, use a methodologically “clean” approach Schema version: major update – 3.0  4.0 Namespace: new namespace  Schema changes are not backwards-compatible, e.g.  removed elements are deleted in the schemas  new code list encoding is implemented using gml:ReferenceType Client software needs to be adapted to accept both the old and new schemas

Versioning – Option 1 x no longer maintained v3.0 v3.1 v3.2 v3.0 deprecated v3.1.1 bugfix minor update (backwards compatible) x no longer maintained

Versioning – Option 2 x no longer maintained v3.0 v3.1 v3.2 v3.0 deprecated v3.1.1 bugfix minor update (backwards compatible) x no longer maintained v3.0 v3.1 v3.0.1 x no longer maintained v4.0 V4.1 v4.0.1 end v3.x maintenance

Comparison Option 1Option 2 Complexity to implement new schemas complex, e.g. new union code list type, dependencies of deprecated elements relatively simple, because changes need not be backwards- compatible Maintenance effort Only one schema version to be maintained Two schema versions to be maintained Clarity of approach hard to communicate, e.g. discrepancy between version number and namespace easier to communicate: two different development lines InteroperabilityOnly one schema version (but with many options)  higher interoperability?  no incentive to move towards new schemas Two schema versions (but with no options)  lower interoperability?  incentive to move towards new schemas Effort for data implementers low if staying with the old options; medium if moving to new options low if staying with the old schemas; medium if moving to new schemas Effort for client implementers medium to support new optionsmedium to support two schemas; difficulties for schema-unaware implementations?