Everyone working in the railway system knows how complex and intertwined it can be. It is the job of our Common coordinator, Thomas Nygreen, to untangle the threads in railML.org’s quest to develop a standardised mark-up language for the railway sector.

What's common coordination?

Each of the working groups of railML.org work on their discipline-specific schemas. The schemas are all interconnected, but they have very different perspectives on some of the same elements. A timetable application may only need to know the name of a station and a list of available station tracks, while an interlocking application may need to know every switch machine. When looking at rolling stock, a timetable planner will need to know a very different set of properties than someone planning a new depot does. And still they will both need to refer to the same rolling stock and be sure that it is indeed the same. It is also important that the definition and interpretation of properties given in one schema is understood in the same way across schemas and throughout the community and different applications. The Common coordinator’s task is to make sure that railML will be a uniform system where the modelling of elements is clear and the same practices are applied across schemas.

Additionally, there are often multiple words used for one element and there is no guarantee that two organisations will have the same descriptions of it either. For example, the words “switch” and “point”, even though they are the same thing, should not be used interchangeably, as it leads to misunderstandings. The different perspectives and requirements within the different schemas and their working groups may lead to different modelling practices. To make it easy to use and develop railML, the common coordinator oversees that common modelling rules are followed across schemas. One such rule is that from now on, no new element or attribute will be allowed into the railML schemas without accompanying documentation.

What's new in railML 3?

The referencing between schemas is a rather complex topic and often there are disagreements regarding the implementation. Therefore, the common coordinator oversees and guides this process. In railML 2, it was necessary to include every element that you wanted to reference in a file. In railML 3, it is possible to reference elements using universally unique identifiers (UUIDs), which can be kept common across files and applications, so that an element does not have to be repeated whenever you need to reference it. However, this increases the difficulty of assuring that a reference actually points to a specific object of the expected type and it requires that the reading software be capable of searching for the references. Therefore, the Common and Timetable coordinators are looking into how the flexibility of UUIDs can be harnessed so that it does not become too demanding for the reading applications.

As a last point, I would like to clarify something to get rid of any confusion. If you have any questions regarding appointments, events, conferences, etc., then the Organisation Team is your contact. Therefore, please email either Joyce or Ronja with your questions. Our common coordinator will just be very confused.

On behalf of everyone at railML.org, I would like to wish everyone a wonderful holiday period with your family and friends and a happy new year. See you all in 2020!