Versioning of importing schema documents

Added by Michael Lutz about 6 years ago

All schema documents that include imports to the updated Annex I schemas should be updated as well. If the updates of the importing schema documents were also considered as minor revisions (rather than bug fixes), this would cause a cascade of new schema versions that would need to be created. It is therefore proposed to treat the updates of import statements in the importing schemas as bugfix releases (i.e. to replace the importing schemas with new schema documents whose import statements point to the updated schema location).

EXAMPLE The current Addresses.xsd (v3.0) schema are imported by the following 3 schemas:
  • /act-core/3.0/ActivityComplex_Core.xsd
  • /base2/1.0/BaseTypes2.xsd
  • /us-govserv/3.0/GovernmentalServices.xsd

If new minor revisions were created for these schemas, too, more than 20 further schema documents would need to be updated (which would yet again cause further schema to be updated).


Replies (4)

RE: Versioning of importing schema documents - Added by Pawel Soczewski almost 6 years ago

Summer is not the best time for additional work ;D

I'll test proposed updated XSD Schema for HY in ArcGIS for INSPIRE. After this weekend I will share the conclusions.

RE: Versioning of importing schema documents - Added by Pawel Soczewski almost 6 years ago

I've tested that idea in AGS for INSPIRE and it seems good. There isn't a lot of work with WFS server reconfiguration.

The XML schemas should be versioned separately from the versioning of data specifications. Not every change in the data specification (new version) can imply the creation of a new XML schema. As well, correction of method for implementing application schema to XML schema doesn't cause creation of a new version of the XML Schema for the same version of the data specification. For the sake of order only number of Major revision should be the same.

RE: Versioning of importing schema documents - Added by Alberto Belussi almost 6 years ago

I agree with your proposal, but I suggest to document that this is not a bug fix but an “import fix”. Moreover, there should be one repository where the different sets of xsd files that are to be managed together are store separately, so that the final user knows which files have to be used together and can understand that she/he cannot mix files from different sets.

(1-4/4)