Home » railML newsgroups » railml.timetable » [railML3] Proposal for new semantic constraints and change of existing ones
| [railML3] Proposal for new semantic constraints and change of existing ones [message #3539] |
Thu, 03 April 2025 18:54  |
Marharyta Vyskarka
Messages: 21
Registered: April 2025
|
Junior Member |
|
|
Dear all,
I propose some constraints and edits to be considered for railML3, all related to references of <baseItineraryPoint>s from <range>s either in <itinerary>, <operationalTrainVariant> or <commercialTrainVariant>.
I propose these constraints:
TT:009: The sequence of <baseItineraryPoint>s referenced by <itinerary>'s <range>s must be a continuous path.
TT:010: <baseItineraryPoint>s referenced by <itinerary>'s <range>s must be increasing in time.
TT:011: <baseItineraryPoint>s referenced by <operationalTrainSection>s' <range>s within an <operationalTrainVariant> must be increasing in time.
TT:012: <baseItineraryPoint>s referenced by <commercialTrainSection>s' <range>s within a <commercialTrainVariant> must be increasing in time.
TT:013: <baseItineraryPoint>s referenced by <identifier>s' <range>s within an <operationalTrainVariant> or <commercialTrainVariant> must be increasing in time.
And based on similarity of <identifier> to <commercialTrainSection> and <operationalTrainSection> in this context, I also propose similar to TT:005 and TT:007 constraint:
TT:014: The first(last) <baseItineraryPoint> of each <identifier> within either <operationalTrainVariant> or <commercialTrainVariant> must either be the referenced <itinerary>'s first(last) <baseItineraryPoint>, or coincide with another <identifier>'s last(first) <baseItineraryPoint>.
Additionally constraints TT:005 and TT:007 and proposed TT:014 would need to be reworded. They describe the relation of first and last<baseItineraryPoint>s of the sequence of train sections' referenced points to the train variant's <itinerary>, but they do not mention the relation of the non-initial/ending points to the <itinerary>, only that they should coincide with another section's point. Adding "that belongs to the referenced <itinerary>" at the end of constraint should fix this.
Also existing constraints TT:004 and TT:006 should be deprecated, as existing constraints TT:005 and TT:007 and proposed constraints TT:011 and TT:012 would make violation of these constraints impossible without violation of one the mentioned ones (TT:005, TT:007, TT:011, TT:012). Constraints TT:005 and TT:007 do not allow direct overlap of <baseItineraryPoint>s in the section due to continuous sequence of coinciding end-start points, and TT:011 and TT:012 would not allow repeating of the coinciding <baseItineraryPoint>s in the sequence due to their increase in time. The constraints TT:011 and TT:12 make more general sense, so they need to be considered instead of existing TT:004 and TT:006.
Please let me know what you think.
Best regards,
Marharyta Vyskarka
|
|
|
|
| Re: [railML3] Proposal for new semantic constraints and change of existing ones [message #3549 is a reply to message #3539] |
Tue, 08 April 2025 11:50  |
Christian Rößiger
Messages: 80
Registered: March 2015
|
Member |
|
|
Hi Marharyta,
so far I have not had the time to think about all of the proposed SemCons in detail, but I wanted to give some feedback in advance:
- Some of your suggestions concern increasing times in baseItineraries. Times in baseItineraries consist of 2 components: a xs:time attribute (00:00:00-24:00:00) and a day offset (integer). So, if we talk about increasing times, both components have to be considered. I would mention this in the SemCon description to avoid misunderstandings.
- Generally I agree, that times within (base-) itineraries should be increasing, but in railML2 we make a difference between times in operational and in commercial trains: We require increasing times for operational trains, but are more tolerant for commercial trains, see: https://wiki2.railml.org/wiki/Dev:Midnight_overrun, example in section "Reference place for day indexes / midnight overruns". For example, it is not strictly forbidden to end at one trainpart/baseItinerary with "23:58:00, dayOffset=0" and to continue the next one at the same station with "00:01:00, dayOffset=0". We will have to discuss, whether we want to keep this "contradiction" in railML3 or find another solution.
Best regards
Christian
|
|
|
|
| Re: [railML3] Proposal for new semantic constraints and change of existing ones [message #3553 is a reply to message #3539] |
Wed, 09 April 2025 19:30 |
Marharyta Vyskarka
Messages: 21
Registered: April 2025
|
Junior Member |
|
|
Hello everyone,
Thank you for the feedback!
The brought up above first point does make sense and the wording for constraints could be changed to having "which is expressed with the components //baseItineraryPoint//times//@time, //baseItineraryPoint//times//@dayOffset and //itinerary/range/@offset" at the end of the definitions.
I also realized a constraint is missing for <baseItinerary> itself. So similar constraint could make sense:
"The times of <baseItineraryPoint>s of the same scope, which are expressed with the components //baseItineraryPoint//times//@time and //baseItineraryPoint//times//@dayOffset, within the same <baseItinerary> must be increasing in time."
As for the second point, yes, the handling of this situation for railML 3 would need to be discussed to determine how it influences the proposed constraints.
Best regards,
Marharyta Vyskarka
Marharyta Vyskarka – Software Developer
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: [railML3] Proposal for new semantic constraints and change of existing ones [message #3554 is a reply to message #3539] |
Wed, 09 April 2025 19:35 |
Marharyta Vyskarka
Messages: 21
Registered: April 2025
|
Junior Member |
|
|
Hello everyone,
I also wanted to note that constraints TT:004 and TT:006 should be deprecated regardless of proposed constraints TT:011 and TT:012, as I came to conclusion that existing constraints TT:005 and TT:007 fully cover this case. Which means that if all the section's end-start <baseItineraryPoint>s coincide as constraints TT:005 and TT:007 describe, the situation described in TT:004 and TT:006 is not possible.
If you have any idea as to why they should not be deprecated, please let me know.
Best regards,
Marharyta Vyskarka
Marharyta Vyskarka – Software Developer
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: [railML3] Proposal for new semantic constraints and change of existing ones [message #3556 is a reply to message #3554] |
Thu, 10 April 2025 09:42 |
David Lichti
Messages: 54
Registered: December 2020
|
Member |
|
|
Good Morning Marharyta,
I have quite some objects to these proposals:
TT:009 What exactly do you mean by continuous path? Whether a sequence of base itinerary points is connected by a continuous, drivable track path is beyon railML.org's capacity to validate. So, it should not be a semantic constraint.
TT:010, TT:011, TT:012, TT:013 This would amount to the railML format enforcing business rules. But railML.org is not a business regulation body. I don't think railML as a data format woul gain much from enforcing any notion of timetable validity. In particular, it would render railML unusable in any context where the validation of schedule times is done on the receiving side of the communication.
Do you mean that the referenced base itinerary points must be well-ordered in the base itinerary? This would be a reasonable constraint. But it should not be based on any timing data.
TT:014 It was an explicit design goal of identifiers that they can overlap each other, even if they are of the same type. Also, I don't think that there is a general need for railML as a data format to enforce that every part of a train is covered by an identifier of any kind. This is in stark contrast to the situation with itinerary ranges, which is why the principles of TT:005 and TT:007 do not apply to identifiers.
TT:004, TT:005, TT:006, TT:007 These constraints were developed together, and they depend on each other to achieve their goal: Each section of a train variant's itinerary must be covered by exactly one train section.
For example, with TT:004 removed, there could be two train sections, both covering the entire itinerary. This would satisfy TT:005, since all referenced base itinerary points are first or last in the underlying itinerary. But such an itinerary sectioning would not make any sense, because each section should describe different parts of the itinerary.
Similarly, with TT:005 removed, there could be just one single train section, with a range from some intermediate base itinerary point to some other intermediate base itinerary point. TT:004 would be satisfied, since there are no other itinerary sections that could overlap. But the train variant would be completely missing a schedule description for the first and last part of the underlying itinerary.
There is, in fact, one flaw with these constraints: They do not enforce a well-ordering of the base itinerary points referenced by a range in a train section that is cancelled or on on request. That is: It would be allowed to have a range where the start base itinerary points comes after the end base itinerary point. If it satisfied TT:005, it would necessarily overlap with some other train section. But that would not be a violation of TT:004 if the parent train section was cancelled or on request.
This would be worth addressing with semantic constraints everwhere ranges are used. But, as explained above, these constraints should be formulated based on the order of base itinerary points in their respective itineraries and base itineraries, not based on any timing information which may or may not be present.
Best regards
[Updated on: Thu, 10 April 2025 09:53] Report message to a moderator |
|
|
|
| Re: [railML3] Proposal for new semantic constraints and change of existing ones [message #3621 is a reply to message #3539] |
Mon, 19 May 2025 16:26 |
Milan Wölke
Messages: 213
Registered: April 2007
|
Senior Member |
|
|
Hi all,
we discussed this at our last timetable developer meeting.
Regarding TT:009 we found that we shouldn't try to make it as strict as the wording above implies. As David pointed out railML.org cannot really verify if the path is actually continuous. Additionally it may actually be required to specify a path that is specifically not continuous in the sense that a train arrives at one track but departs from another. There is railways that actually operate trains like that. In the end we would propose an updated wording for TT:009:
When combining baseItineraries in an itinerary it shall be ensured that the last baseItineraryPoint of the ending baseItinerary references that same operational point as the first baseItineraryPoint of the starting baseItinerary.
Regarding the proposed semantic constraints TT:010-TT:013 we came to the conclusion that railML should be able to also communicate timetables that are not finished or not consistent. A possible use case for this which we actually supported in railML 2.x was that a system exports a timetable and another specialized system analyses that timetable and outputs issues and errors with it. For this use case to work it is necessary to also communicate times that are inconsistent with each other.
We also reviewed your proposal to deprecate the semcons TT:004 and TT:006 in favor of TT:005 and TT:007 because a possible redundancy. During the meeting a colleague was able to show that there actually is no redundancy. Your argument was that it is not possible to violate TT:005/TT:007 which explains that one part of an trainSection needs to end at the point another starts without also violating TT:004/TT:006 which ensures that there is no overlaps between trainSections of a trainVariant. One example where you could violate TT:005 without breaking TT:004 is if you have 2 train sections starting and ending at the same point. This would be in line with TT:005 but is a violation according to TT:004. As such we would argue that the existing semcons TT:004, TT:005, TT:006 and TT:007 shall remain.
Best regards, Milan
Milan Hoffmann – Timetable schema coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: [railML3] Proposal for new semantic constraints and change of existing ones [message #3624 is a reply to message #3621] |
Tue, 20 May 2025 12:28 |
Milan Wölke
Messages: 213
Registered: April 2007
|
Senior Member |
|
|
Another idea we discussed was the introduction of yet another rule, saying that the baseItineraryPoints referenced by start and end of the range of an operationalTrainSection or a commercialTrainSection should be increasing with regard to their sequence numbers. What makes things hard to find a good wording, is that these baseItineraryPoints may belong to different baseItineraries. Logically this is not a problem as the ranges of the itinerary have a sequence number as well but when it comes to creating a semcon wording for this it gets complicated.
I would propose the following wording for this issue:
In an <operationalTrainSection>, the <range> element's @start and @end must reference <baseItineraryPoint> elements such that their order aligns with the sequencing defined by the <itinerary>.
Specifically:
If the start and end points belong to different <baseItinerary> elements, the <range> elements referencing these <baseItinerary>s in the <itinerary> must have increasing @sequenceNumber.
If both points belong to the same <baseItinerary>, their own @sequenceNumber must increase from start to end.
The same would probably be needed for commercialTrainSections.
What do you think would this wording work? Is it understandable enough? Am I missing a case?
Best regards, Milan
Milan Hoffmann – Timetable schema coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
[Updated on: Tue, 20 May 2025 13:07] Report message to a moderator |
|
|
|
| Re: [railML3] Proposal for new semantic constraints and change of existing ones [message #3663 is a reply to message #3624] |
Thu, 26 June 2025 12:54 |
Milan Wölke
Messages: 213
Registered: April 2007
|
Senior Member |
|
|
Hi all,
during our last timetable developer meeting we discussed the proposed wording for TT:009 and found that it lacked definition of how the order of referenced baseItineraries is described in the semcon. With the following updated wording I am trying to improve on that.
When combining baseItineraries in an itinerary it shall be ensured that the last baseItineraryPoint of the preceding baseItinerary references that same operational point as the first baseItineraryPoint of the succeeding baseItinerary. The order of the baseItineraries is determined by the sequenceNumber specified in the range of the itinerary.
Please let me know if this is clear. When you read this, do you understand how things are meant to be?
Thanks in advance for any feedback.
Best regards, Milan
Milan Hoffmann – Timetable schema coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: [railML3] Proposal for new semantic constraints and change of existing ones [message #3664 is a reply to message #3624] |
Thu, 26 June 2025 13:43 |
Milan Wölke
Messages: 213
Registered: April 2007
|
Senior Member |
|
|
We also discussed the wording for the newly proposed semcon for operationalTrainSection and commercialTrainSection. We decided that we should only stick to the general rule in the semcon and move the explanatory sentences to the best practice section of the wiki page. This would mean that the semcon wording would be like this:
In an <operationalTrainSection>, the <range> element's @start and @end must reference <baseItineraryPoint> elements such that their order aligns with the sequencing defined by the <itinerary>.
For the explanatory text it was pointed out that also baseItineraries with just a single baseItineraryPoint are possible and should be considered in the wording. This would mean the core explanation for the semcon would be like this:
If the start and end points belong to different <baseItinerary> elements, the <range> elements referencing these <baseItinerary>s in the <itinerary> must have increasing @sequenceNumber.
If both points belong to the same <baseItinerary>, their own @sequenceNumber must increase from start to end, unless the baseItinerary consists of only a single baseItineraryPoint.
Please let us know what you think. Clear enough, or would you have trouble understanding the intended regulation.
Best regards, Milan
Milan Hoffmann – Timetable schema coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: [railML3] Proposal for new semantic constraints and change of existing ones [message #3668 is a reply to message #3664] |
Wed, 09 July 2025 14:26 |
Milan Wölke
Messages: 213
Registered: April 2007
|
Senior Member |
|
|
Hi all,
during the last timetable developer meeting we decided go forward with the two semantic constraints above:
TT:009:
When combining baseItineraries in an itinerary it shall be ensured that the last baseItineraryPoint of the preceding baseItinerary references that same operational point as the first baseItineraryPoint of the succeeding baseItinerary. The order of the baseItineraries is determined by the sequenceNumber specified in the range of the itinerary.
TT:010:
In an <operationalTrainSection>, the <range> element's @start and @end must reference <baseItineraryPoint> elements such that their order aligns with the sequencing defined by the <itinerary>.
We will decide about approval of these in one of the next modelling telcos among the coordinators.
Best regards, Milan
Milan Hoffmann – Timetable schema coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
[Updated on: Wed, 09 July 2025 14:26] Report message to a moderator |
|
|
|
Goto Forum:
Current Time: Mon Feb 09 09:42:22 CET 2026
|
Members
Search
Help
Login
Home
