Home » railML newsgroups » railml.timetable » [railML2+3] Proposed semantic constraint for <times>
[railML2+3] Proposed semantic constraint for <times> [message #3393] Tue, 19 November 2024 12:46 Go to next message
Milan Wölke is currently offline  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 #3395 is a reply to message #3393] Tue, 19 November 2024 14:04 Go to previous messageGo to next message
David Lichti is currently offline  David Lichti
Messages: 40
Registered: December 2020
Member
I'd suggest adding the word 'element' for more precision:

  • railML 2: ocpTT element
  • railML 3.2: baseItineraryPoint element
  • railML 3.3: stop/pass element
When dealing with composite itineraries, the same stop may be represented by two different ocpTT/baseItineraryPoints in two different trainParts/baseItineraries. In this case, the semantic constraint should not be understood to preclude having times of the same scope in both instances of ocpTT/baseItineraryPoints.
Re: [railML2+3] Proposed semantic constraint for <times> [message #3400 is a reply to message #3395] Thu, 21 November 2024 16:35 Go to previous messageGo to next message
Milan Wölke is currently offline  Milan Wölke
Messages: 157
Registered: April 2007
Senior Member
During todays timetable developer meeting we discussed the wording of this semantic constraint. We made minor changes and ended up with the following text:

No two attributes //times/@scope of the same enclosing stop/pass elements shall have the same value.

The new proposed semantic constraint was added to the following pages:
https://wiki2.railml.org/wiki/TT:times_ocpTT_ocpsTT_trainPar t#Semantic_Constraints_/_Semantische_Beschrnkungen
https://wiki2.railml.org/wiki/TT:times_ocpTT_ocpsTT_patternT rainPart#Semantic_Constraints_/_Semantische_Beschrnkungen
https://wiki3.railml.org/wiki/TT:times#Semantics
https://wiki3.railml.org/wiki/TT:stop:times#Semantics
https://wiki3.railml.org/wiki/TT:pass:times#Semantics

We will review this at the next timetable developer meeting and if no counter arguments are raised (here or otherwise) we will accept this constraint.

Please let us know if you have concerns or ideas for improvement.

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 Go to previous message
Milan Wölke is currently offline  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
Previous Topic: [railML2] Proposed semantic constraint for <specialService>
Next Topic: [railML2] Wording of semantic constraints TT:015 and TT:016
Goto Forum:
  


Current Time: Mon Jan 20 13:54:35 CET 2025