Home » railML newsgroups » railML.infrastructure » Extension suggestion for <upTime> (uptime, railML 2.4nor, railML2.5, railML3 development)
Re: Extension suggestion for <upTime> [message #2355 is a reply to message #2330] Wed, 26 February 2020 21:58 Go to previous messageGo to previous message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Torben Brand wrote on Mon, 17 February 2020 15:06
Dear railML-community,

For the Norwegian railway sector, we are looking for a way to model an ocp, that is unmanned on certain timely restrictions. The restrictions we would like to model are specific days, for example Saturdays or public holidays.

The element <upTime> (https://wiki2.railml.org/index.php?title=IS:uptimeWink makes it possible to state that an ocp is unmanned with @mode="unmanned". But it doesn't give us the possibility to restrict this property to certain days, but only certain times in a day with @from and @until.

The element <propOther/states/state> on the other hand would give us the option to refer to an operating period via @operatingPeriodRef and thus makes it possible to model restrictions for certain days (in the sub element <operatingDay>).

We would like to propose a solution to extend the element <upTime> with the time attributes of <state>: @operatingPeriodRef and @endDayOffset. The existing attributes @from and @until seem to be semantically equivalent to @startTime and @endTime. So, we suggest keeping them as is, but to change their semantic constraint from mandatory to optional.

Dear Torben, dear all,

the current implementation of <ocp><propOperational><uptime> is not usable for regular/repeating time patterns as descibed by you. Your proposal to add an attribute @operatingPeriodRef as it is already available in <ocp><propOther><states><state> sounds reasonable.

However, for version compatibility reasons (within railML 2.x), we are not able to set <uptime> attributes @from and @to from mandatory to optional. Further, I see a semantic overlap between the usage of <ocp><propOperational><uptime> and <ocp><propOther><states><state>. I would like to solve this potential conflict by clarifying the current practical usage of both elements. Therefore, any feedback from the community is very much welcome.

Thank you very much and best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Suggested extension for operating rules
Next Topic: Re: [railML3]: special infrastructure in IL - bascule bridge, tunnel gates
Goto Forum:
  


Current Time: Tue Apr 30 06:51:00 CEST 2024