[railML2+3] Proposed semantic constraint for <times> [message #3393] |
Tue, 19 November 2024 12:46 |
Milan Wölke
Messages: 157 Registered: April 2007
|
Senior Member |
|
|
Hello community,
during our last timetable developer meeting we discussed about introducing a semantic constraint for the <times> element. The general idea is to clarify that when multiple instances of <times> are given for a ocpTT (railML 2) or baseItineraryPoint (railML 3), each value of @scope should only be used once at most. We want to make sure there are no two scheduled departure times for the same stop.
This would apply to //ocpTT/times in railML 2, as well as //baseItineraryPoint/times in railML 3.2 and //baseItineraryPoint/pass/times and //baseItineraryPoint/stop/times in railML 3.3.
We would propose the following wording: No two attributes //times/@scope of the same stop/pass shall have the same value.
What do you think? Any ideas for improving the wording? Any concerns that something wouldnt work anylonger that should be working?
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: [railML2+3] Proposed semantic constraint for <times> [message #3417 is a reply to message #3400] |
Mon, 06 January 2025 09:15 |
Milan Wölke
Messages: 157 Registered: April 2007
|
Senior Member |
|
|
During the last timetable developer meeting we accepted the above semantic constraint with a minimal adjustment of wording. For railML 3.x the times are not necessarily enclosed in the stop/pass element, nor does railML 2.x have explicit elements for this. The wording will be individually adapted to reflect the scenario where it is used.
Best regards, Milan
Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|