For all developers of railML interfaces the railML Wiki is the first point of contact for background information and questions concerning the programming of interfaces. Therefore, a constant maintenance and clear categorization of the contents, and an extension of the technical possibilities in order to meet state of the art usability is of great importance for the entire railML community. In the past six months, amongst many small things, the following major work has been carried out:

• Descriptions of currently missing elements of all railML subschemas were added. This allows the community to quickly identify the need for additions.
• Further Timetable concepts have been incorporated into the wiki. These short explanations give an overview of timetabling specialities (e.g. midnight overrun, train coupling and sharing, etc.) and how these are implemented in the timetable schema. 
• An overview of the national usage of the track Attribute "type" has been established and uploaded to the wiki. Currently Norway, Germany, Switzerland, the Netherlands and the Czech Republic are part of the comparison.
  Your country is missing? Please let us know about your national understanding of the track type and we will extend the list.
• The usage of the namespaces was defined more precisely. For more information please read the corresponding forum post.
• The standard template for the documentation of elements was updated. Attributes are now united, as well as the Example & Best Practice sections.
• The XML tree was updated to railML 2.3 and its correct display implemented in the railML Wiki.
• The railML Simple Example has been transferred to the railML Wiki. It enables a brief overview of railML infrastructure modelling and is a good starting point for railML newcomers.
• The first schema changes between railML 2.3 and the upcoming version 2.4 were summarized in the wiki. The overview will be extended during the soon starting beta phase.

Currently the railML documentation team is working at designing and implementing a completely new railML 3 Wiki. Main challenge and innovation is an automatic derivation of wiki content from UML/XSD to the media wiki code. With this technology, which has not yet been implemented in the open source world, a constant consistency of model and documentation can be ensured and the development team will "only" have to take care of adding background information and examples. A group of railML. org coordinators and external developers are currently taking care of the final steps towards this novelty. It is expected to be launched as soon as the remaining technical and workload/financing issues are solved, latest in early summer 2018.