From railML 2 Wiki
Jump to: navigation, search
XML Railway exchange format
Latest release: 2.4
(October 7th, 2018)
Main Menu
XML tree
Use cases
Versions & Changes
Note.png The subject of this article are official version releases. If you are interested in accessing, setting and naming developer versions, see dev:versioning.

Release Policy

Major Release

Commited changes have affects on XML-instance files and should be announced in advance in corresponding railML-newsgroups.
Tagging a major release after railML conferences' consensus
Version number 
Increasing first digit, e.g. version="2.0"
Changing the year in the namespace string, e.g. xmlns=""

Minor Release

Commited changes have no affects on XML-instance files, but on other coordinators' XSD-schema files.
Commits of new elements, types and/or attributes are allowed.
Tagging a minor release after railML coordinators' consensus
Version number 
Increasing second digit, e.g. version="2.1"
Up to railML 2.x the year changed in the namespace string. This policy will be changed from railML 3.1 on the way it was originally intended: not changing the namespace string. e.g. xmlns="".


Corrigendum commits and cosmetic changes with no affect on XML-instance files are allowed.
Tagging a corrigendum after railML coordinators' consensus
Version number 
Increasing third digit, e.g. version="2.0.1"
No influence on the namespace string, e.g. xmlns=""

Unofficial/Developers Version

Depending on the current policy only Subversion commits for corrigendum, minor or major railML® releases are checked into the repository for further feature development.
User requirements from the forum are kept in the railML® Trac tickets. The railML coordinators prioritize them, code each single topic in a railML®ish way and commit changed files into the Subversion repository. See also Officially released versus developer version for more information.
Version number 
Each atomic Subversion commit is tagged with the increasing Subversion number. The last official version number is expanded by the Subversion release number. e.g. version="2.1r460"
No influence on the namespace string, e.g. xmlns=""

Version numbers and corresponding namespaces

How to describe the version number of a railML® file? Or to find out which version a railML® file belongs to?

Version numbers

You will find a version attribute in the railML® root element <railml> as well as in the root elements of the sub-schemas as <infrastructure>, <rollingstock>, <timetable>. This attribute is to be used for the version number of the railML® schema the XML file is based on.

Major, minor and corrigendum version are separated by a dot, the release number is separated by r. Corrigendum and release number are optional:

<major version>.<minor version>[.<corrigendum>][r<release number>]

The following rules apply:

  • The release number is required to be omitted if a railML® file is based on an official released railML® version. This applies to railML®'s release numbers
 * 2.0r270 has to be given as 2.0,
 * 2.1r409 has to be given as 2.1,
 * 2.2r602 has to be given as 2.2,
 * 2.4r668 has to be given as 2.3,
 * 2.4r862 has to be given as 2.4 and
 * 3.1r989 has to be given as 3.1, all respectively without release number.
  • The release number shall be considered mandatory in all other cases, e. g. if it is "an unofficial release version" but an intermediate. For more information on the relevance of intermediate versions see Officially released versus developer version.
  • The attribute version of the root element of the railML® file shall be considered mandatory. If the root element of the railML® file is <railml>, the attribute version of the subsequent elements <infrastructure>, <rollingstock>, <timetable> are optional. If they are used, they have to be identical to the version of <railml>.
  • The corrigendum release number is mandatory, if the release is tagged this way. Otherwise it shall be ommited.

This official railML® version number should not be confused with an implementation dependent software version in the metadata elements dc:format and/or dc:identifier.

railML® namespace declarations

As above mentioned the XML namespace does also change with the railML version. The following table shows this relationship for all official railML versions.

railML version number railML namespace string remote schema location HTTPS access
1.0 no namespace different schema locations for sub-schemas no
1.1 no
2.0 yes, optional
2.1 yes, optional
2.2 yes, optional
2.3 yes, optional
2.4 yes, mandatory
3.0 (alpha & beta only) Alpha & Beta phases finished no
3.1 yes, mandatory

The XML file should declare the same XML namespace (identical string) as defined by its corresponding XML Schema. For general information about namespaces see Defining namespaces and validating railML files.

A railML® file based on an intermediate release with remote schema location shall refer to the Subversion repository of the release. This is<release number>


railML file of official released railML version 2.0, remote schema location:

<?xml version="1.0" encoding="UTF-8"?>
<railml version="2.0"

railML file of intermediate release #416 (between official releases 2.1 and 2.2) , remote schema location:

<?xml version="1.0" encoding="UTF-8"?>
<railml version="2.1r416"