Home » railML newsgroups » railml.timetable » forgotten attribute <operatingPeriod> @dayOffset and its future
forgotten attribute <operatingPeriod> @dayOffset and its future [message #1602] Fri, 09 June 2017 12:02 Go to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Introduced with railML 2.2, there should be a new attribute @dayOffset at <operatingPeriod>.

It now turned out that this attribute seems simply to have been forgotten.
(The attribute with the same name at <blockPartSequence> is already there since railML 2.0 and therefore no mistake.)

So obviously nobody has missed this attribute and the question arises, whether we should still introduce it and/or transfer it into railML 3.x.

There is a lengthy explanation of this attribute in [1] including several reasons for its introduction. So my suggestion is to introduce @dayOffset at <operatingPeriod> from r2.4 AND transfer it into r3.x.

@Stefan Jugelt: I know several infrastructure managers who do not allow "departureDay=1" at the first <ocp> in their data models. How does ERA deal with this issue? Is there a kind of "dayOffset" in TAP/F TSI, too, or is there "departureDay=1" allowed from the start?

Best regards,
Dirk.

[1] http://wiki.railml.org/index.php?title=TT:Midnight_overrun
Re: forgotten attribute <operatingPeriod> @dayOffset and its future [message #1611 is a reply to message #1602] Tue, 20 June 2017 00:22 Go to previous messageGo to next message
Philip Wobst is currently offline  Philip Wobst
Messages: 47
Registered: November 2013
Location: Hanover, Germany
Member
Hello Dirk,

I do not agree with need to add this attribute in r2.4. Due to the fact that it seems to not have been used at all in any r2.2 interface should rather mean we remove the attribute in the Wiki in a transparent way and then review the need for this attribute in r3.x

Best regards,

Philip
Re: forgotten attribute <operatingPeriod> @dayOffset and its future [message #1614 is a reply to message #1611] Wed, 21 June 2017 12:57 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Dear Philip,

the fact that the attribute has not been used so far does not mean that there is no demand on it. I think simply the programming lags behind several years. That's normal.

I can remember that there was an original problem to introduce this attribute and a lengthy discussion between <TT> developers at a meeting. I want to respect the earlier decision. I think this is important also in general, to give the developers stability and "protection of investment".

However, if you want to waive the attribute, that means to allow departureDay<>0 at first <ocpTT>. No problem of technology from my side, but as I said, there are several infrastructure managers who do not allow it in their data models. So could we please clarify first what ERA says to this problem in their recommendations? I think it is not reasonable to let railML walk into a different solution than ERA.

Best regards,
Dirk.
Re: forgotten attribute <operatingPeriod> @dayOffset and its future [message #1638 is a reply to message #1614] Mon, 04 September 2017 10:59 Go to previous messageGo to next message
Philip Wobst is currently offline  Philip Wobst
Messages: 47
Registered: November 2013
Location: Hanover, Germany
Member
Dear all,

there has been no further feedback regarding the need of this attribute in railML 2.4. The description needs to be removed from the wiki on the following pages:
https://wiki.railml.org/index.php?title=TT:Midnight_overrun
https://wiki.railml.org/index.php?title=TT:operatingPeriod
https://wiki.railml.org/index.php?title=TT:times

Best regards,

Philip Wobst
Re: forgotten attribute <operatingPeriod> @dayOffset and its future [message #1656 is a reply to message #1638] Tue, 17 October 2017 14:53 Go to previous messageGo to next message
Christian Rößiger is currently offline  Christian Rößiger
Messages: 59
Registered: March 2015
Member
Dear all,

I adapted the wiki pages listed below. The changes have not been
published yet, but can be found under "Pending changes" on each article
page. It was not enough to only remove the paragraphs concerning the
obsolete attribute, I also had to rearrange and merge several paragraphs
to preserve a consistent structure of the article, so my changes were a
little bigger than expected.
I also replaced two references to the iRFP document
"http://www.irfp.de/download/railml_beispiel_mueg.pdf" (RailML-Beispiel
zu Mitternachtsübergängen) because its content is already available in
the wiki article http://wiki.railml.org/index.php?title=TT:Midnight_overrun
For details of the changes please see my comments under "View history".

Kind regards
Christian Rößiger


Am 04.09.2017 um 10:59 schrieb Philip Wobst:
> there has been no further feedback regarding the need of
> this attribute in railML 2.4. The description needs to be
> removed from the wiki on the following pages:
> https://wiki.railml.org/index.php?title=TT:Midnight_overrun
> https://wiki.railml.org/index.php?title=TT:operatingPeriod
> https://wiki.railml.org/index.php?title=TT:times
>
> Best regards,
>
> Philip Wobst


--
iRFP e. K. · Institut für Regional- und Fernverkehrsplanung
Hochschulstr. 45, 01069 Dresden
Tel. +49 351 4706819 · Fax. +49 351 4768190 · www.irfp.de
Registergericht: Amtsgericht Dresden, HRA 9347
Re: forgotten attribute <operatingPeriod> @dayOffset and its future [message #1657 is a reply to message #1656] Mon, 23 October 2017 16:21 Go to previous messageGo to next message
Christian Rößiger is currently offline  Christian Rößiger
Messages: 59
Registered: March 2015
Member
Dear all,

Respecting the input from our telephone conference today I reworked the
article https://wiki.railml.org/index.php?title=TT:Midnight_overrun
again. (My changes can be seen under "Pending changes").

Kind regards
Christian Rößiger

Am 17.10.2017 um 14:53 schrieb Christian Rößiger:
> Dear all,
>
> I adapted the wiki pages listed below. The changes have not been
> published yet, but can be found under "Pending changes" on each article
> page. It was not enough to only remove the paragraphs concerning the
> obsolete attribute, I also had to rearrange and merge several paragraphs
> to preserve a consistent structure of the article, so my changes were a
> little bigger than expected.
> I also replaced two references to the iRFP document
> "http://www.irfp.de/download/railml_beispiel_mueg.pdf" (RailML-Beispiel
> zu Mitternachtsübergängen) because its content is already available in
> the wiki article http://wiki.railml.org/index.php?title=TT:Midnight_overrun
> For details of the changes please see my comments under "View history".
>
> Kind regards
> Christian Rößiger
>
>
> Am 04.09.2017 um 10:59 schrieb Philip Wobst:
>> there has been no further feedback regarding the need of
>> this attribute in railML 2.4. The description needs to be
>> removed from the wiki on the following pages:
>> https://wiki.railml.org/index.php?title=TT:Midnight_overrun
>> https://wiki.railml.org/index.php?title=TT:operatingPeriod
>> https://wiki.railml.org/index.php?title=TT:times
>>
>> Best regards,
>>
>> Philip Wobst
>
>


--
iRFP e. K. · Institut für Regional- und Fernverkehrsplanung
Hochschulstr. 45, 01069 Dresden
Tel. +49 351 4706819 · Fax. +49 351 4768190 · www.irfp.de
Registergericht: Amtsgericht Dresden, HRA 9347
Re: forgotten attribute <operatingPeriod> @dayOffset and its future [message #2367 is a reply to message #1602] Wed, 04 March 2020 16:58 Go to previous messageGo to next message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 66
Registered: March 2008
Member
I'm sorry for bringing back this old thread. I stumbled upon it without realising its age. I've deleted my comments.

Best regards,
Thomas Nygreen - Common schema coordinator, railML.org


Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

[Updated on: Wed, 04 March 2020 17:04]

Report message to a moderator

Re: forgotten attribute <operatingPeriod> @dayOffset and its future [message #2372 is a reply to message #2367] Mon, 09 March 2020 10:08 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Dear Thomas,

thank you for your good analysis of my posts on this topic over several years. I still think there is a misunderstanding:

- It is true that in 2012, I argued for throwing away of the attribute @dayOffset at <operatingPeriod> for the sake of less redundancy.

- In [1], there are arguments against the usage of shifted <operatingPeriod>s in the section "Why not use shifted/rotated <operatingPeriod>s".

- So what to do after midnight when there is no attribute @dayOffset at <operatingPeriod> and shifting of the <operatingPeriod> is not wanted? The only solution left is using departureDay<>0 at first <ocpTT>. And for this, I already wrote on 09.06.2017 and 21.06.2017:

> No problem of technology from my side, but as I said, there are several infrastructure managers who do not allow it in their data models.

So again: We can life without the attribute @dayOffset at <operatingPeriod>, but that means allowing departureDay<>0 at first <ocpTT>. This is less redundancy but more incompatibility to other data models of infrastructure managers who expect departureDay=!0 at first <ocpTT>.

Unfortunately my direct question to Stefan Jugelt of ERA, how is it done in TAP/F TSI, was not answered yet.

So as there seems to be no current problem, I think we can leave it for now and can come possibly back to that discussion in railML 3.x timetable operating periods.

Best regards,
Dirk.

[1] http://wiki.railml.org/index.php?title=TT:Midnight_overrun
Re: forgotten attribute <operatingPeriod> @dayOffset and its future [message #2387 is a reply to message #2372] Tue, 10 March 2020 13:15 Go to previous message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 66
Registered: March 2008
Member
Den 09.03.2020 10:08, skrev Dirk Bräuer:
>> No problem of technology from my side, but as I said, there are several infrastructure managers who do not allow it in their data models.
>
> So again: We can life without the attribute @dayOffset at <operatingPeriod>, but that means allowing departureDay<>0 at first <ocpTT>. This is less redundancy but more incompatibility to other data models of infrastructure managers who expect departureDay=!0 at first <ocpTT>.

There will always be data models out there that differ from the railML
data model. As long as we can reflect the information that those data
models need, I don't see a problem. In this case, a system with a native
data model that differs from railML can simply add/subtract/shift on
import/export. Creating redundancy in the model to be closer to more
native data models makes import interfaces more complicated for everyone.


Best regards,
Thomas Nygreen - Common schema coordinator, railML.org


Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Previous Topic: Formation versus TrainParts
Next Topic: blockPart mission="other:..."
Goto Forum:
  


Current Time: Thu Mar 28 12:01:20 CET 2024