| [railML 3] New semantic constraint for trainVariant [message #3057] |
Mon, 13 March 2023 17:22  |
Milan Wölke
Messages: 131
Registered: April 2007
|
Senior Member |
|
|
Hi all,
in the last few timetable developer group meetings we have been discussing another semantic constraint in order to help understanding the new timetable model and in order to improve data exchange. This time it is focused on the operationalTrainVariant as well as the commercialTrainVariant. We propose for both of these to define the following semantic constraint:
Quote:
When calculating which <commercialTrainVariant> of a <commercialTrain> is valid on a particular day always a maximum of one active <commercialTrainVariant> shall be the result. If the result is more than one <commercialTrainVariant>, all except one shall be marked as <isCancelled> or <isOnRequest>.
The above wording exists in the same way for the operationalTrainVariant.
From our point of view this should help make it clear how to export and how import a railML 3 timetable. What do you think? Do you have use cases in mind where this semantic constraint would be a burden?
Best regards, Milan
Milan Wölke - Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: [railML 3] New semantic constraint for trainVariant [message #3061 is a reply to message #3057] |
Wed, 15 March 2023 13:39  |
David Lichti
Messages: 13
Registered: December 2020
|
Junior Member |
|
|
This may be a more general topic: But how is the interaction of semantic constraints with custom extensions?
For example, if there was an extension adding a flag for propsed trains, f.ex. <ext:isProposed>. That train would be neither cancelled (because it hasn't been published), nor on-request (because it hasn't been agreed). In such a case it would be reasonable to have more than one proposed variant for one day.
|
|
|
|
Members
Search
Help
Login
Home
