A Look Behind the Scenes: Use Case-Driven railML® Development

At its core, the railML initiative has always been driven by community dedication. This is especially true in regard to the development of the railML^® schema itself, particularly the introduction of new use cases.

What Is a Use Case?

The railML^® schema consists of four subschemas: Timetable, Infrastructure, Interlocking and Rolling Stock. Within these schemas, use cases are utilised to describe, characterise, standardise and register potential scenarios. A use case can belong to more than one subschema.

Ultimately, a railML use case is defined as an application of data exchange between at least two IT systems in the railway domain. The objective of the use case description is to establish the technical implementation requirements for the data exchange.

Development and Documentation of railML Use Cases: the Workflow

Essentially, the process of use case development can be divided into three stages:

1. Textual description (idea phase)
2. XSD development (technical implementation and global definition)
3. Use case element specification table (detailed description and documentation of use case)

Step One: Textual Description of Use Case

New use cases are oftentimes derived from the railML community. Usually, suggestions on further railML applications are made by members of railML working groups and first discussed in said setting. However, to pitch a new use case to railML, you don’t have to be a member of a working group. Instead, outline your use case, select the corresponding subschema and send an email to its coordinator. Follow the link to find an overview of the current railML schema coordinators and their contact information.

After communicating with the schema coordinator and the railML organisational team, the person / organisation submitting the use case will be asked to provide additional, structured information by filling out the “use case submission template”.

As a next step, railML will arrange for other members of the community to provide their feedback on the draft of the use case textual description. Once the feedback process (which may loop) is completed, railML consolidates the textual description by publishing it in the railML Wiki3 – both in a dedicated subpage and in the use case overview table.

Step Two: XSD Development

After the basic concept of the new use case is documented, the process of technical implementation begins. The XSD (XML Schema Definition) is developed by a railML programmer. This might include defining new <elements> or verifying how existing <elements> could be applied. Also, inter-use-case-requirements must be implemented, which means that global “grammar” and “semantics” have to be defined for the new <elements> (e.g. what <values> or <attributes> can be added).

Again, a review process takes place. This time, the XSD (alpha version) is reviewed by the community member who introduced the use case in the first place. Once the review is complete and all suggestions are implemented, the XSD is published on the railML.org website as a beta version, or only partially as a UML.

Once the beta version is online, a call for review will be made public, e.g. within the working groups, at conferences, and of course on the railML website. How long this second review process may continue is limited by the general railML version timeline, i.e. the process will be concluded before the set corresponding railML version release date. Once adjustments in development suggested by reviewers are completed, the XSD is released as a final version.

At this stage, best practices for the new use case are curated by railML or community members and put into the Wiki (see e.g. this example of modelling Rolling Stock in railML3).

Step Three: Use Case Element Specification Table

Finally, the specific rules for the correct application of the new use case are documented in the “use case element specification table”. Said table is developed by the community, usually in a working group. All interested parties are welcome to join in this process, however, long term commitment is required (several months up to several years). Within the same working group, the table is reviewed with focus on whether all use case specific requirements have been implemented. Once the review is completed, the table is released by railML and published in Gitlab.

If all use case specific requirements are implemented, the process of use case development is complete. If not, however, either an update of the use case specification table suffices, or the whole development process starts from the very beginning in case it is decided that new <elements> must be included.