During the last railML.org-timetable developer meeting, which took place in Berlin on the 2^nd of June, 2016, the present modellers discussed the further development strategy of the railML.org subschema timetable. The publishing of railML 3 initiated by the infrastrucutre subschema gives the unique opportunity to cast off contemporary habits. An intensive debate about various controversy ideas was the main component of this meeting.

For certain is that the timetable subschema developers want to use the opportunity of refactoring with this upcoming next major version change in 2017. One big point of criticism is that the railML 2.x subschemes produce a huge amount of redundancy by repeating the arrival & departure times at each <trainPart> of a <train>. In future, this should be avoided by separating itineraries from trains and trainparts.

Also concern exists about some aspects of train identification (external primary keys), which is in some special aspects (such as multiple use of train numbers) currently orientated at German timetable data of DB Netz. This may be justified by DB Netz being one of the Infrastructure Managers with the highest number of trains, but possibly it can be managed to create a more international model that involves more European countries. Furthermore most of the open tickets should/would be solved with a refactoring.

An approach is constituted by modelling with the help of containers. The changes will be published as a timetable subscheme in railML's version 3.x. The date of the official release is not fixed, though it will certainly be after the release of railML 3.1 which will probably only contain the infrastructure and maybe interlocking subscheme. An official announcement will be made during the next railML conference in November 2016.

Minutes

The minutes are available in the railML's timetable forum for the comments and participation of the community.