Forum: railML.infrastructure » [railML2] extension suggestion for the element <state> for open time period

Home » railML newsgroups » railML.infrastructure » [railML2] extension suggestion for the element <state> for open time period

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

[railML2] extension suggestion for the element <state> for open time period [message #2676]

Mon, 08 March 2021 11:50

Torben Brand
Messages: 162
Registered: March 2016

Senior Member

Background:
The element <state> is part of railML2.4 and is used to define the status of infrastructure pieces with a given time frame for a certain duration. It is a sub-element that can be placed under nearly all infrastructure elements.

Suggestion:
The element <state> should be enhanced to be able to function outside the range of <operatingPeriod>.
In railML2.4, the timeframe for state is defined for days with the usage of @startDate and @endDate in <operatingPeriod> and more refined for the time within those days with the @startTime, @endTime and @endDayOfset in <state> . This model is restricted by:
- The timeframe must be closed. I.e. both @startDate and @endDate in <operatingPeriod> must be used.
- A timeframe of the <timetablePeriod> must be set.
- The timeframe of <operatingPeriod> must be within the timeframe of the <timetablePeriod>.
- The <timetablePeriod> can be as short or as long as required.

This restricts the UC requirements for:
- open time period: only a start date or end date is set
- time period outside the <timetablePeriod> and thus outside the <operatingPeriod>

For more details see document "railML2.4nor Infrastructure Documentation" (https://www.jernbanedirektoratet.no/railML), version 1.4, 17.12.2020, point 4.14.

Jernbanedirektoratet suggest adding in railML2.5 the attributes to <state>:
@startDate: First day the stated status is valid for. If no @startTime is set the status is valid from the beginning of the day.
@endDate: Last day the stated status is valid for. If no @endTime is set the status is valid until the end of the day.

Suggestion for syntactic constraint:
@operatingPeriodRef: shall only be used in cases of recurring time periods, e.g. a certain element is closed each Tuesday

What does the community think?

Report message to a moderator

Re: [railML2] extension suggestion for the element <state> for open time period [message #2699 is a reply to message #2676]

Fri, 09 April 2021 18:05

christian.rahmig
Messages: 463
Registered: January 2016

Senior Member

Dear Torben,

time aspects in infrastructure states are an important topic indeed. Therefore, I very much appreciate any comments and ideas from the community on our way to identify an appropriate solution.

My proposal: instead of defining single attributes for day and time, let's focus on only two new attributes for a state:
* @startDateTime (xs:dateTime) to specify begin date AND time for the state
* @endDateTime (xs:dateTime) to specify end date AND time for the state

xs:dateTime is specified in the pattern: "YYYY-MM-DDThh:mm:ss" (see [1]).

Both attributes shall be optional meeting your requirement of having "open time spans".

I am curios to hear from the community about their ideas...

[1] https://www.w3schools.com/XML/schema_dtypes_date.asp

Best regards
Christian

Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: [railML2] extension suggestion for the element <state> for open time period [message #2720 is a reply to message #2699]

Thu, 20 May 2021 12:53

Torben Brand
Messages: 162
Registered: March 2016

Senior Member

This depend on the UC for the attribute! Our initial request is for open timeframes for an infrastructures state where you cannot reference an <operatingPeriod> (they need to be closed). Here it would make sense to have both date and time together in one attribute as suggested.

But note when you use @operatingPeriodRef for closed timeframes within an <operatingPeriod> or for cyclical day occurrences with the usage of operatingPeriod<operatingDay> these elements do not contain time attributes and are supplemented with the three attributes introduced in railML2.4: <state>@startTime @endTime and @endDayOffset.

If your suggestion is to keep (not deprecating) these three attributes and add new the two attributes @startDateTime and @endDateTime this is fine for us. Note a very clear semantic constraint should be written when to use @startTime and when to use @startDateTime in the wiki.

Report message to a moderator

Re: [railML2] extension suggestion for the element <state> for open time period [message #2723 is a reply to message #2720]

Fri, 21 May 2021 13:21

christian.rahmig
Messages: 463
Registered: January 2016

Senior Member

Dear Torben,

thank you for your feedback. I updated the Trac ticket #394 [1] with a railML 2.5 solution proposal including semantic rules for the different scenarios of usage. The rules are:

* use @startDateTime and/or @endDateTime to specify an open or closed timespan for the state's validity that is not linked with an <operatingPeriod>
* use @startTime and/or @endTime (and @endDayOffset) to specify an open or closed timespan for the state linked with an <operatingPeriod> where @startDate and/or @endDate are defined

Are these rules sufficient?

[1] https://trac.railml.org/ticket/394

Best regards
Christian

Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: [railML2] extension suggestion for the element <state> for open time period [message #2751 is a reply to message #2723]

Mon, 07 June 2021 13:37

Dominik Looser
Messages: 18
Registered: March 2020

Junior Member

Adding the @startDateTime and @endDateTime attributes is a good idea and I agree that @startTime and @endTime should then only be used together with an <operatingPeriod>.

Report message to a moderator

Re: [railML2] extension suggestion for the element <state> for open time period [message #2754 is a reply to message #2751]

Fri, 11 June 2021 12:00

christian.rahmig
Messages: 463
Registered: January 2016

Senior Member

Dear Dominik,

thank you for your feedback. I added the proposed semantic rules in the Trac ticket #394 [1] to be added into the wiki documentation of the new attributes. The new attributes will be implemented in the railML 2.5 schema.

[1] https://trac.railml.org/ticket/394

Best regards
Christian

Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Previous Topic:	railML 2.3 infrastructure extension proposal line sections
Next Topic:	[railML2] modeling of a car ramp

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Sat Sep 21 04:19:12 CEST 2024