Best Practice For Updating and Versioning of TDWG Standard XML Schemas
Walter G. Berendsohn, Andrea Hahn, Anton Güntsch, Chuck Miller, Javier de la Torre, Markus Döring, Neil Thomson, Patricia Mergen, Renato De Giovanni, William Ulate, Wouter Addink
Abstract
The ABCD (Access to Biological Collection Data) Schema version 2.06 was proposed as a TDWG standard by the ABCD content definition subgroup and ratified by the TDWG meeting in St. Petersburg in 2005.
ABCD provides a provisional mechanism for extending the schema, by including extension elements (typed as xs:any) in three locations: at the level of the unit, within site descriptions and within identification results. These elements serve as slots for the inclusion of third-party-schemas (or parts thereof), and can help to avoid duplicating the efforts of other communities in developing data models (e.g. for geographical data). The ABCD extension elements also provide a support mechanism to allow user communities to add missing elements to the current version. Such elements can then be treated as candidates for formal inclusion in future versions.
A new version of the ABCD schema can be released whenever a significant number of necessary additions and changes have accumulated and/or structural changes are urgently needed. The changes can then be integrated using a new namespace for the new version of the ABCD schema.
Several problems were recognised during the implementation of the latest version of the ABCD schema. These show that an additional mechanism for is required for correcting errors between the release of new versions. The ABCD subgroup met in July 2006 and developed a mechanism which can be used to version and update the XML schemas currently in use as TDWG standards.
The group proposes that the example of GML should be followed for these interim corrections, i.e. that the schema should be changed without changing the namespace but in a way that ensures full backward compatibility. Any corrections must not introduce changes which will break applications using previously approved versions of the schema in the same namespace. The root element of the schema should include a version attribute indicating the schema version number. This number should agree with the namespace assigned to the schema. Minor changes are then indicated by letters. For example, the first interim version of ABCD 2.06 should receive be identified as 2.06a.
In practical terms, backward compatibility is maintained when
• no elements or attributes are deleted (although elements may be marked as deprecated)
• no elements or attributes are renamed
• the semantics of all elements are left unchanged
• type changes are restricted to assigning types to previously untyped elements
• new elements are added
The changes between v. 2.06 to 2.06a are documented in detail on the ABCD Wiki (http://ww3.bgbm.org/abcddocs/). The main changes consisted of defining types for several untyped elements that escaped attention during the last version upgrade, eliminating some points of confusion concerning contact information in metadata, adding a new extension slot at the dataset level to allow the metadata to be extended and the addition of several elements for better compatibility to the Darwin Core and the HISPID standard.
ABCD provides a provisional mechanism for extending the schema, by including extension elements (typed as xs:any) in three locations: at the level of the unit, within site descriptions and within identification results. These elements serve as slots for the inclusion of third-party-schemas (or parts thereof), and can help to avoid duplicating the efforts of other communities in developing data models (e.g. for geographical data). The ABCD extension elements also provide a support mechanism to allow user communities to add missing elements to the current version. Such elements can then be treated as candidates for formal inclusion in future versions.
A new version of the ABCD schema can be released whenever a significant number of necessary additions and changes have accumulated and/or structural changes are urgently needed. The changes can then be integrated using a new namespace for the new version of the ABCD schema.
Several problems were recognised during the implementation of the latest version of the ABCD schema. These show that an additional mechanism for is required for correcting errors between the release of new versions. The ABCD subgroup met in July 2006 and developed a mechanism which can be used to version and update the XML schemas currently in use as TDWG standards.
The group proposes that the example of GML should be followed for these interim corrections, i.e. that the schema should be changed without changing the namespace but in a way that ensures full backward compatibility. Any corrections must not introduce changes which will break applications using previously approved versions of the schema in the same namespace. The root element of the schema should include a version attribute indicating the schema version number. This number should agree with the namespace assigned to the schema. Minor changes are then indicated by letters. For example, the first interim version of ABCD 2.06 should receive be identified as 2.06a.
In practical terms, backward compatibility is maintained when
• no elements or attributes are deleted (although elements may be marked as deprecated)
• no elements or attributes are renamed
• the semantics of all elements are left unchanged
• type changes are restricted to assigning types to previously untyped elements
• new elements are added
The changes between v. 2.06 to 2.06a are documented in detail on the ABCD Wiki (http://ww3.bgbm.org/abcddocs/). The main changes consisted of defining types for several untyped elements that escaped attention during the last version upgrade, eliminating some points of confusion concerning contact information in metadata, adding a new extension slot at the dataset level to allow the metadata to be extended and the addition of several elements for better compatibility to the Darwin Core and the HISPID standard.