Home » railML newsgroups » railml.timetable » Attribute processStatus to be declared deprecated for <train>, <trainPart> and <trainGroup>
Attribute processStatus to be declared deprecated for <train>, <trainPart> and <trainGroup> [message #2242] Thu, 29 August 2019 17:59 Go to next message
Milan Wölke is currently offline  Milan Wölke
Messages: 36
Registered: April 2007
Member
Hallo,

bei der letzten Timetable Entwickler Telco wurde beschlossen, dass mit der Version railML 2.5 das Attribut @processStatus am <train>, <trainPart> und <trainGroup> für deprecated zu erklären. Hintergrund ist, dass es für dieses Attribut keine standardisierte Semantik gibt und die Teilnehmer, die dieses Attribut verwenden erklärten, dass sie die Verwendung mittelfristig durch andere dem Standard entsprechende Modellierungen ersetzen wollen.

Sollte es in der Community weitere Verwendungen dieses Attributes geben, so bitte ich diese hier zu kommunizieren. In diesem Fall würde die Entscheidung nochmals diskutiert werden müssen. Vielen Dank schon mal im Voraus.

------------------------------------------------------------ ---

at the last Timetable developer Telco it was decided that with version railML 2.5 the attribute @processStatus am <train>, <trainPart> and <trainGroup> should be declared deprecated. The background is that there is no standardized semantics for this attribute and the participants who use this attribute declared that they want to replace the use with other standard compliant representations in the medium term.

If there are other uses of this attribute in the community, please communicate them here. In this case the decision would have to be discussed again. Many thanks in advance.

Best regards, Milan
Re: Attribute processStatus to be declared deprecated for <train>, <trainPart> and <trainGroup> [message #2258 is a reply to message #2242] Tue, 15 October 2019 13:43 Go to previous messageGo to next message
Milan Wölke is currently offline  Milan Wölke
Messages: 36
Registered: April 2007
Member
Ticket for this issue was created at https://trac.railml.org/ticket/364
Ein Ticket für diesen Vorgang wurde unter https://trac.railml.org/ticket/364 angelegt.


Milan Wölke - Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: Attribute processStatus to be declared deprecated for <train>, <trainPart> and <trainGroup> [message #2323 is a reply to message #2242] Thu, 06 February 2020 15:08 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 89
Registered: March 2016
Member
The Norwegian railML community uses @proccessStatus in it's data exchange via railML. We even plan to extend the use with other:*. We suggest to adopt these other: values in railML2.5/3 or to adopt them in the mentioned (but unpublished) new solution in the initial forum posting.
The background UC for the use of @proccessStatus is:
• UC:TT:LongTermStrategicTimetabling
• UC:TT:ATimetableForACompetition
• UC:TT:SlotOrdering

We plan to extend to values in @processStatus to form the complete life cycle of a train(part). This from pre designed conceptual slots from a governmental agency that oversees developing the rail network over operators giving bids to the infrastructure manager approving the timetable.

We use the attribute @proccessStatus and not @pathStatus as it gives us more flexibility as it is placed on <trainPart>, <train> and <trainGroup>. @pathStatus is only under <trainpartSequence>. This "middle position" gives an implicit referring to the parent <train> and the child <trainPart>. We would like to be more flexible. Especially as we are working on extensions for <trainGroup> and using <trainPart> without a <train> to make generic path descriptions (forum post currently in draft).

What happened with the development idea for a general sub element <status> (similar to IS:state) in this forum string?: https://www.railml.org/forum/index.php?t=msg&goto=578&am p;&srch=status#msg_578

We should consolidate the enumeration lists in @proccessStatus and @pathStatus (and maybe even look to IS:state@status?) and think for a proper placement in the scheme.

In principal we like the enumeration list in @pathStatus extended with a "conceptual" value and the "actual" value from @proccesStatus.

Both enumeration lists (@proccessStatus and @pathStatus) lack definition of their values. This should be amended. We have some suggestions.

I would like to ask the TT coordinator or the stated participants who use this attribute and have declared that they "want to replace the use with other standard compliant representations in the medium term", to declare the intended replacement here in the forum.
Re: Attribute processStatus to be declared deprecated for <train>, <trainPart> and <trainGroup> [message #2331 is a reply to message #2323] Mon, 17 February 2020 15:53 Go to previous messageGo to next message
Christian Rößiger is currently offline  Christian Rößiger
Messages: 38
Registered: March 2015
Member
Hello,

we discussed the future of the "processStatus" attribute during the
railML telephone conference, as the documentation in the wiki is
inadequate and none of the participants could provide a plausible way of
using it. All participants of the telephone conference currently using
this attribute use the attribute in a different context, so that a
functioning exchange is unlikely. Furthermore, only a few of the
possible values of the enumeration are used or the value range is
extended by individual "other:xxx" values. For this reason, we have
proposed to declare the attribute as "deprecated".
For mapping different planning states or versions of a train I would
suggest to introduce a new attribute or element to avoid confusion. For
this purpose we would appreciate a modeling suggestion from you. If you
want to keep the existing attribute "processStatus", we would also be
interested in information about which values of the enumeration you use
and what exactly is encoded with them.
I would not try to merge "pathStatus" and "processStatus". With
"pathStatus" different states of a train are described during a train
path allocation process. A train can have several different pathStatus
if it is ordered at several different infrastructure managers. I
understand the "pathStatus" attribute here as additional information of
a train. The new attribute for the planning statuses, on the other hand,
should help to distinguish different instances of <train> elements, so
it becomes part of an external primary key of a train/train part. For
these reasons I would also leave "pathStatus" at <trainPartSequence> and
the new attribute at <trainPart> / <train> / <trainGroup>.

Best regards
Christian Rößiger

--
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: Attribute processStatus to be declared deprecated for <train>, <trainPart> and <trainGroup> [message #2333 is a reply to message #2331] Wed, 19 February 2020 12:23 Go to previous messageGo to next message
Milan Wölke is currently offline  Milan Wölke
Messages: 36
Registered: April 2007
Member
Hi,

i think this issue can be linked with the topic discussed here. A discussion in the timetable developer group showed that in order to communicate a track change the use of a status like element is to be preferred over some individual modelling for the use case of a track change. This would have the benefit to be able to communicate all kind of changes to trains (track change, formation change, etc).
Looking at the requirements mentioned in the other thread, it should be possible to express the originator of the change (or reason for the new version) as well as the time when this change occured. Furthermore the timetable developer group discussion considered introducing some kind of version counter which would allow to describe different version within the same planning state.
In general I still think that processStatus needs to be replaced with some new well defined element to express state information, since as Christian pointed out data exchange regarding the state seems highly unlikely given the different semantics currently in use by implementing systems.

Best regards, Milan


Milan Wölke - Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

[Updated on: Wed, 19 February 2020 12:24]

Report message to a moderator

Re: Attribute processStatus to be declared deprecated for <train>, <trainPart> and <trainGroup> [message #2335 is a reply to message #2331] Wed, 19 February 2020 13:57 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 89
Registered: March 2016
Member
Dear TT community,

We value the quick reply and the suggestions by iRfP. However, we suggest not to make a new attribute, but to reuse @proccesStatus, as a pragmatic approach, as railML2 is in the end of its life cycle (But as they say in German: "the doomed live the longest ;-)"). This will NOT alter the values or the use of @pathStatus. We suggest reconstructing a cleaner model in railML3. Especially one that is aligned with the new TTR process of Rail Network Europe (http://rne.eu/sales-timetabling/ttr/).

Jernbanedirektoratet has discussed the TT process stages including the slot allocation process with the Norwegian IM Bane NOR. We have reached a common suggestion for a flexible and pragmatic implementation suggestion in railML2.

The general process phase/stage of the model is global for the railML file/transmission. This stage should be submitted, if desired, in the <metadata> element of railML. As these stages differ per country/IM today and differ in TTR we suggest NOT to standardise this information. An example for the global file @proccesStatus/@pathStatus metadata information could be:
<dc:source>proccesPhase: tactical (long term timetable negotiations) SubPhase: (X-5) Slot proposal published (offer from IM back to operators after their initial slot order) </dc:source>.

We have generalised the phases/stages of a timetable from idea to actual operated train (also see illustration) to the values: strategic, tactical, operational, historic. These could be used in the metadata together with more detailed description (see example above).

The individual elements could use the set value list of @pathStatus. For completeness we suggest extending the value list in either end of the timeline with "conceptual" and "actual".

We suggest the following value definitions:

We refer to "element" as being either trainPart, trainPartSequence, train or trainGroup

"conceptual" for slot construction or commissioning of the element, which is planned for the medium or long term. However, there are still no concrete (planning) activities for the construction of the element beyond the preliminary planning. Used in UC/phase TT:LongTermStrategicTimetabling and as a draft example from the commissionaire in UC/phase TT:ATimetableForACompetition.

"planned": The construction or commissioning of the element is planned concretely and at short notice or concrete planning activities for the construction take place, e.g. design, approval or implementation planning, cost calculation, award of contracts (bid). It is not normally possible to use the element (run the train) as it has not been ordered and approved. Used in the proposal in UC/phase TT:ATimetableForACompetition and in UC/phase TT:SlotOrdering.

"ordered" The element is ordered for a slot allocation process from the bid party (railway undertaking/operator) to the capacity allocation authority (infrastructure manager).

"detailsRefused" The element has been reviewed (by the capacity allocation authority) and details have been modified/changed/adjusted pending approval by the initial ordering/bid party.

"confirmed" The element has been reviewed and approved (by the capacity allocation authority) as ordered by the initial ordering/bid party.

"cancelled" The element has been cancelled, but service will be maintained through a train replacement service (usually a buss). The service will be announced. Used in combination with @cancellation="true"

"notAvailable" The element has been retraced and there will be no other (train) service. This possible due to an error in the planning. The service will not be announced. Used in combination with @cancellation="true"

"actual" These are actual driven/operated trains and the time values with time@scope="actual" CAN have been set.

We suggest making the value list more flexible placeable. Comparable to IS:state which is placed on several elements including the <infrastructure> root element. For this we suggest to use, in addition to @pathStatus,@proccesStatus as this is already available under <train>, <trainPart> and <trainGroup>. In railML2.5 it should be considered placing the attribute also on <timetable> for a set global value that inherits/apply to all elements unless defined further down the hierarchy and thus breaking/overwriting the inherited value.
This makes it also possible to mix different process state values for different trains in the same file. For instance, you can indicate "conceptual" trains to indicate a desired template/pattern (but which shall never run as actual trains) on a <trainGroup> together with the "confirmed" trains (that run later in the process after the path allocation has been closed unless operative cancelled) on <train>.

With the correct use of other:* and extended to the Norwegian use case we will use the following values:
@pathStatus="nor:conceptual" and "nor:actual" in addition to the existing values.
@processStatus="nor:conceptual","planned","nor:ordered", "nor:confirmed","nor:detailsRefused","nor:cancelled","nor:notAvailable " and "actual".

We suggest NOT to use in @processStatus the values: "calculated", "toBeChecked", "changed" and "imported". This as the general data state can be set in <metadata> (calculated/imported) and annotations can be set in combination with @proccessStatus/pathStatus (toBeChecked/changed).

Example:
An operator orders 6 train slots at two IM's. All train@processStatus="ordered". Additionally, the operator delivers a pattern train with trainGroup@proccesStatus="conceptual" to indicate the desired pattern for a service.
The review of one of the IM's result in: two of the trains are partially outside its jurisdiction. The but the part inside its area is ok for one train (trainPartSequence@pathStatus="confirmed"), but can only be accommodated for one of two trainParts for the other train (trainPart@proccesStatus="notAvailable" and "confirmed" for the other) For the remaining 4 trains completely inside it's area 2 trains are ok as ordered (train@proccesStatus="confirmed" or trainPartSequence@pathStatus="confirmed" for all trainPartSequence of the train). For one train some of the departure times of a trainPart must be adjusted (trainPart@proccesStatus="detailsRefused") and the last train cannot be accommodated at all (train@proccesStatus="notAvailable").

Please note that this is just a suggestion and should not interfere with existing use of railML.

PS. I was not able to upload a picture or an PDF attachment to this reply. And formating is a cumbersome afair in the forum. So I have placed a pdf with formating and illustrations here:
http://cloud.railml.org/index.php/s/JeZ5qNffx8Aetqz (public link that will expire 4.3.2020 as set by the cloud system)

Documentation of attribute "pathStatus" and proposal for new value "offered" [message #2341 is a reply to message #2323] Mon, 24 February 2020 12:08 Go to previous messageGo to next message
Christian Rößiger is currently offline  Christian Rößiger
Messages: 38
Registered: March 2015
Member
Hello,

[German Text below]

for the currently missing description of the allowed values of the
attribute "pathStatus" in the railML wiki I would offer the following
interpretation:

planned: The train is planned for ordering at the infrastructure manager
(IM), but no order has yet been transmitted (initial state).
ordered: The train has been ordered at the IM.
confirmed: The IM has submitted an offer for a train path to the railway
undertaking (RU) and the RU has accepted this offer.
detailsRefused: I have no idea what this value represents.
cancelled: The RU has cancelled the train at the IM.
notAvailable: The IM has rejected the order of then train path.

From my point of view, the value "offered" (between "ordered" and
"confirmed") is missing in this enumeration, which describes the status
that the train path was offered by the IM to the RU.

Best Regards,
Christian Rößiger

[German]

für die derzeit fehlende Beschreibung der möglichen Werte des Attributs
"pathStatus" im railML-Wiki würde ich folgende Interpretation anbieten:

planned: Der Zug ist für die Bestellung beim Infrastruktur-Manager (EIU)
vorgesehen, es wurde aber noch keine Bestellung übermittelt (initialer
Zustand).
ordered: Der Zug wurde beim EIU bestellt.
confirmed: Das EIU hat ein Trassen-Angebot an das Verkehrsunternehmen
(EVU) übermittelt und das EVU hat dieses Angebot angenommen.
detailsRefused: Ich habe keine Ahnung, was mit diesem Wert ausgedrückt
werden soll.
cancelled: Das EVU hat den Zug beim EIU storniert.
notAvailable: Das EIU hat die Bestellung des Zuges abgewiesen.

Aus meiner Sicht fehlt in dieser Enumeration der Wert "offered"
(zwischen "ordered" und "confirmed"), mit dem der Status beschrieben
wird, dass die Trasse vom EIU an das EVU angeboten wurde.

Viele Grüße
Christian Rößiger
--
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: Documentation of attribute "pathStatus" and proposal for new value "offered" [message #2349 is a reply to message #2341] Wed, 26 February 2020 15:21 Go to previous messageGo to next message
Milan Wölke is currently offline  Milan Wölke
Messages: 36
Registered: April 2007
Member
Hi all,

I think detailsRefused refers to the reply when an order of a train is refused by the IM. If I understand correctly the IM may also include a counteroffer annotated with that @processState.

What I dont really understand is how to work with the proposed @processStatus "cancelled". I get the feeling that this state isnt the same kind of @processStatus as the rest of the suggested values. I also get the feeling that we break the semantics of the @cancellation attribute of train and trainPart by introducing this, because the behavior of the importing system would need to change when evaluating the attribute @cancellation depending on what the @processStatus is saying.

The same applies to the @processStatus in general. I think, although railML 2.x ist at the end of its lifecycle, we shouldnt alter the behavior of existing attributes. We can add new ones, alright, but changing existing ones is something we always tried to avoid in the past for the sake of compatibility. Accordingly I would rather introduce a new element <status> for train, trainGroup and trainPart. I also think that an element would be a better choice here in order to store additional metadata regarding the state(change), like when did the state change to the current value.

Best regards, Milan


Milan Wölke - Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
[railML2] Re: Documentation of attribute "pathStatus" and proposal for new value "offered" [message #2416 is a reply to message #2349] Tue, 07 April 2020 15:36 Go to previous message
Milan Wölke is currently offline  Milan Wölke
Messages: 36
Registered: April 2007
Member
Hi all,
in the last timetable developer phone conferences we discussed about the different enum values of @pathStatus. We came to the conclusion that the current states of @pathStatus are not enough for modelling of a basic slot ordering process. Therefore we decided to extend the enum with two new values: offered and conceptual. The general idea of the statemachine behind that is the following:

A train starts out as "conceptual", which means that a slot for that train is not to be ordered (yet).
If a slot for a train is to be ordered but no order has been issued yet, the train is annotated with the state "planned".
Once a slot for a train has been ordered the state "ordered" is used. Now the IM will have to respond to the order. The possible results of that could be: "notAvailable", if the IM cannot fulfill the request; "offered", if the IM can provide the requested slot or "detailedRefused" if the IM cannot fulfill the request but offers a slot that is similair to the requested one.
If the IM is chooses "detailsRefused" or "offered" in the response to the request is up to the IM. Very often an offered slot of the IM will not be exactly fitting the requested one. By choosing "offered" or "detailedRefused" the IM can decide if from his point of view the request is fully complied with or not and inform the RU accordingly.
If the slot offered by the IM suits the RU the state "confirmed" is used. If it is not, the state "cancelled" is used to cancel the ordering process.

As I said initially this means introducing two new states: conceptual as a new starting point and allowing to include trains in railML that are not (yet) ready for the ordering process; and offered for the IM to indicate that a request has been fully complied with.

If it is necessary to encode further states for modelling slot ordering those states should be defined using other:anything.

@Torben: Would you agree with the meaning and usage of the existing and new enum values of @pathStatus.

Best regards, Milan


Milan Wölke - Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Previous Topic: Multiple ocpTT within a station
Next Topic: TT:007 - stop on request for passenger trains only?
Goto Forum:
  


Current Time: Thu Apr 09 14:59:46 CEST 2020