Home » railML newsgroups » railml.misc » [railML3] Handling changes between minor versions
[railML3] Handling changes between minor versions [message #2460] Tue, 16 June 2020 10:20
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 27
Registered: March 2008
Junior Member
Dear community!

As announced in this month's news article on railML.org the coordinators have been discussing compatibility between minor versions of railML 3.x. On the one hand, full compatibility results in very little flexibility to correct mistakes or improve concepts that have already been modelled in railML. On the other hand, full flexibility to make changes means we cannot guarantee compatibility between minor versions. In railML 2.x the policy has been and will continue to be that we allow new elements and attributes, but keep downward compatibility by deprecating unwanted elements and attributes instead of removing them.

railML 3.x is even more comprehensive than, and has been completely remodeled from, railML 2.x. We can expect the increased practical application of railML 3.x to result in proposals for changes that will further improve the standard. That leaves us with the question of how we should balance flexibility to improve versus the need for stability and compatibility. The coordinators are proposing the following three alternatives:

  1. Follow the path of railML 2.x in railML 3.x: downward compatibility will be guaranteed. Changes may lead to elements or attributes being deprecated, but not removed.
  2. Changes may lead to elements or attributes being deprecated. Elements and attributes that are deprecated in one minor version will be removed in the following minor version. Compatibility is only guaranteed between one minor version and the next.
  3. Changes may lead to elements or attributes being removed in a new minor version, without first being deprecated. No compatibility guaranteed.
Please post your feedback here before August 31st to allow us to include it in the development of railML 3.2, scheduled for beta release around the end of 2020.


Thomas Nygreen - Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Previous Topic: Namespace not recognised for v3.1 (v2.4 works!)
Next Topic: Problems with changed schemaLocation (http -> https) for Dublin-Core schema
Goto Forum:
  


Current Time: Wed Jul 08 08:25:26 CEST 2020