| [railML2] Re: Meaning and usage of @shuntingTime [message #2447 is a reply to message #1944] |
Wed, 27 May 2020 16:38   |
Vasco Paul Kolmorgen
Messages: 55
Registered: November 2004
|
Member |
|
|
Dear all,
in the today's railML 3 developer meeting we discussed the shunting time
too. This reminded us to solve this this long-standing for railML 2.5 too.
Therefore I want to remind for the already opened ticket (see
https://trac.railml.org/ticket/343) and your opinion for railML 2.5 (in
this thread) and/or railML 3.2 (in a new thread).
Best regards,
--
Vasco Paul Kolmorgen - Governance Coordinator
railML.org (Registry of Associations: VR 5750)
Phone railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Am 03.09.2018 um 12:18 schrieb Dirk Bräuer:
> Dear Heribert,
>
> thank you for your reply. No objections from my side.
>
>> 1. The values in <times> also have a scope: actual,
>> calculated, published, scheduled etc.. The shuntingTime as
>> attribute of <ocpTT> does not have this scope and the
>> assignment would therefore be problematic.
>
> Yes, I agree.
>
>> 4. Since we have very different use cases for data transfer
>> with RailML, I would not restrict flexibility at this
>> point.
>
> Ok. I agree that the question "what does @shuntingTime mean" can only be answered by a use case.
>
> So far, we can only summarise that we have no known use case and do not know how to use @shuntingTime. So, I would not like to add any example.
>
> However, we still should avoid to have two competing @shuntingTimes. So, there is still my suggestion to declare one or both as deprecated.
>
> At the today's <TT> developer telephone conference, it was agreed to open a "ticket" to fix that at least one @shuntingTimes should become deprecated from a future railML <TT> version.
>
> With best regards,
> Dirk.
|
|
|
|
Members
Search
Help
Login
Home
