values 'earliest' and 'latest' of <ocpTT>.<times>.@scope [message #1848] |
Mon, 18 June 2018 19:44 |
Dirk Bräuer
Messages: 313 Registered: August 2008
|
Senior Member |
|
|
Dear all,
during the last weeks, a question arose about the meaning of the values 'earliest' and 'latest' of the attribute
<ocpTT>.<times>.@scope
and Vasco created an "information missing" note therefore.
To make progress and solve the question, I'd like to make the following suggestions:
1) 'Earliest' and 'latest' are _not_ intended to encode the "slot" every timetable has by its supplement: They are not to be used as a redundancy to <ocpTT>.<sectionTT>.<runTimes>.@operationalReserve, @additionalReserve, @minimalTime. It is normal that every timetable defines a "slot" of times rather than an exact time - 'run time' is a random variable in a physical sense.
2) 'Earliest' and 'latest' are probably intended to define a "wish" of a customer in the use case of "slot ordering": The customer likes to order a slot with the earliest departure at... or with the latest arrival at... It that meaning, it would fit to the other scopes: While 'scheduled' and 'published' are later planning states (and 'actual' is probably the latest because the train already runs), 'earliest' and 'latest' are early planning states because they define something like the "first idea" of the timetable of a train.
If my above thesis will be agreed, I see two possibilities:
a) Declare 'earliest' and 'latest' as deprecated because they do not easily fit into the current philosophy of arrival and departure times in railML: A wish of an earliest departure or latest arrival probably only makes sense at the very first / last <ocpTT> and implies to give only one <ocpTT> with <times>. All other <ocpTT>s may be given to define the wished route but do only make sense without <times>.
b) Legalise the above mentioned usage and clarify it at Wiki.
I think we should decide for one of the two options in the near future. So, please, don't hesitate to write your selection here!
Dirk.
|
|
|