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 next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
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.
Re: values 'earliest' and 'latest' of <ocpTT>.<times>.@scope [message #1928 is a reply to message #1848] Mon, 27 August 2018 15:28 Go to previous message
Heribert Neu is currently offline  Heribert Neu
Messages: 7
Registered: January 2018
Junior Member
Hello Dirk,

I agree with your assumptions. Earliest and latest are data from the order process.

The times should still be kept in one place <times>, even if they are not expected or present at all ocpTT in some use cases. Therefore earliest and latest should not be declared as deprecated.

As a consequence, however, only an example of the use of earliest and latest in the wiki needs to be added. I do not believe that anything needs to be legalized.

Best Regards
Heribert
Previous Topic: stopDescription: New enumeration value 'none' for attribute onOff in railML 2.4
Next Topic: train stablings
Goto Forum:
  


Current Time: Fri Apr 19 19:16:32 CEST 2024