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: 4
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: 79
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 #3556 is a reply to message #3554] |
Thu, 10 April 2025 09:42 |
David Lichti
Messages: 51
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 |
|
|
|
Goto Forum:
Current Time: Sat May 03 19:23:54 CEST 2025
|
Members
Search
Help
Login
Home
