Home » railML newsgroups » railml.timetable » Production interfaces with further limitations (How is certification done on if the standard more constrainted?)
Production interfaces with further limitations [message #2328] Wed, 12 February 2020 21:00
Stefan de Konink is currently offline  Stefan de Konink
Messages: 2
Registered: August 2019
Junior Member
As a producer of RailML we would like to go for certification of our interface as-is. If we comply with the RailML standard, we expect that a certified consumer would be able to use our data. It seems that this is not true, which surprises us greatly.

For example something trivial like the code attribute on Block. One of the consumers of a production interface stating to support RailML mandates this attribute is filled with a decimal value.

The wiki https://wiki2.railml.org/index.php?title=TT:block seems to be clear on it.

code (introduced with version 2.1): Machine-interpretable string (e.g. an abbreviation) used for identification of the object across exchange partners, usecase specific uniqueness constraints may apply.
Maschineninterpretierbare Zeichenkette (z.B. Abkürzung), die zur Identifizierung des Objekts auch bei Austauschpartnern verwendet wird, wobei spezifische Eindeutigkeitsbeschränkungen gelten können.
This is the short string which is known for identifying the block across the involved staff.

code: xs:string, optional

Could someone elaborate how this consumer could have a certified RailML interface, but not supporting the types defined in the standard?
Read Message
Previous Topic: Formation versus TrainParts
Next Topic: Published station track vs actual station track
Goto Forum:

Current Time: Fri Feb 28 18:23:19 CET 2020