Home » railML newsgroups » railml.timetable » values 'earliest' and 'latest' of <ocpTT>.<times>.@scope
values 'earliest' and 'latest' of <ocpTT>.<times>.@scope [message #1848] Mon, 18 June 2018 19:44 Go to previous message
Dirk Bräuer is currently offline  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.
 
Read Message
Read Message
Previous Topic: stopDescription: New enumeration value 'none' for attribute onOff in railML 2.4
Next Topic: train stablings
Goto Forum:
  


Current Time: Mon Oct 14 13:00:47 CEST 2024