Home » railML newsgroups » railml.timetable » [railML 3] LTP and STP Variants
[railML 3] LTP and STP Variants [message #3444] Tue, 21 January 2025 09:43 Go to next message
David Lichti is currently offline  David Lichti
Messages: 57
Registered: December 2020
Member
Dear Community,

In the context of our railML timetable export, we need to differentiate the original train variants from the LTP timetable, and all the new variants due to short term changes in the STP process.

Within an operational or commercial train, there would typically be one or more LTP variants. All other variants result from modifications of these reference variants. We propose to mark the original reference variants with an <isLtpVariant> element.

In trains with more than one reference variants, it may not be clear, which LTP variant the different STP variants are based on. This is, for example, important to understand the differences between the effective STP timetable, and the original LTP timetable. We propose to add a @validityRef attribute to the <isLtpVariant> element. It would represent the validity of the reference variant in the LTP timetable.

This does not affect the semantics of the @validityRef attribute in the <operationalTrainVariant> and <commercialTrainVariant> elements. In particular, the semantic constraint TT:002 still applies with respect to that validity. The effective validity of the variant would usually always be contained within the original LTP validity. In the extreme case, the original timetable has been changed on every operating day. The LTP variant may still be included in the export, but with an empty effective validity.

What do you think about this approach, or alternatives?

Best regards

David

[Updated on: Tue, 21 January 2025 09:44]

Report message to a moderator

Re: [railML 3] LTP and STP Variants [message #3457 is a reply to message #3444] Thu, 06 February 2025 18:01 Go to previous messageGo to next message
Milan Wölke is currently offline  Milan Wölke
Messages: 230
Registered: April 2007
Senior Member
Hi David,

again, thanks for the suggestion. I do understand your requirement. But to be honest, when reading the solution I get the feeling this is too limited. Like this you can only distinguish between two levels of timetable. I do like the idea that in edge cases where a base version basically is replaced completely by other variants you indicate that it is no longer effectively used by specifying an empty validity.

What speaks against reversing the relationship you propose? So that the derived variant points to its (conceptual) predecessor? This reference would also have a validity to describe which days of the predecessor version are fulfilled by the referencing one. Wouldnt that also fulfill your requirement? Or do you need a classification of the level of planning? Drawback would probably be that reconstructing the original validity of the ancestor requires collecting all predecessor reference validities? Is that a key requirement of yours?

What do you think about this approach? What does the community think?

Best regards, Milan

Milan Hoffmann – Timetable schema coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

[Updated on: Mon, 10 February 2025 17:24]

Report message to a moderator

Re: [railML 3] LTP and STP Variants [message #3461 is a reply to message #3457] Wed, 12 February 2025 11:33 Go to previous messageGo to next message
David Lichti is currently offline  David Lichti
Messages: 57
Registered: December 2020
Member
This is really about stating the factual operating days of train variants in different planning stages. Not so much about conceptual relationships between train variants. In practice, an STP variant would usually be based on the overlapping LTP variant. But it may just as well be based on a completely different LTP variant, with which it does not have any operating day overlap. So, this implied relationship may not be entirely fitting.

With the predecessor approach, we would need the possibility to add more than one predecessor reference. Each with its own validity.

And on LTP variants, there would be a self-reference with the same validity as is given in the validityRef attribute. This would allow to recognize them even if there were no STP variants.

Still, this approach has the issue that some of the information about the LTP variants is actually located in the STP variants.

A more flexible approach for a future standard would be to move the validityRef attribute into its own sub-element, and add a scope attribute. This would be similar to the times element. But for consistency reasons, this should completely replace the validityRef attribute.
<operationalTrainVariant>
  <validityRef ref="va-1" scope="LTP"/>
  <validityRef ref="va-2" scope="STP"/>
  <validityRef ref="va-3" scope="other:..."/>
</operationalTrainVariant>

Best regards

Report message to a moderator

Re: [railML 3] LTP and STP Variants [message #4061 is a reply to message #3461] Mon, 22 June 2026 15:32 Go to previous message
Milan Wölke is currently offline  Milan Wölke
Messages: 230
Registered: April 2007
Senior Member
Hi all,

after discussing this in the timetable developer group we came to a somewhat different design. The problem with the proposed additional @scope attribute was, that when using for example other, a train that actually just represents an intermediate state may actually be imported as a non-intermediate by a system that does not support the extension.
The alternative we actually added to the schema and which will become available with railML 3.4 is the following:
Instead of a single element type operationalTrainVariant we introduced cancelledTrainVariant as well as onRequestTrainVariantm under operationalTrainVariants. The versions mentioned above (LTP and STP) have not been added. The idea, however, is to extend the parent type operationalTrainVariants and a repeatable instance of for example ltpTrainVariant to the operationalTrainVariants container.
This way the requirement can be fulfilled without running the risk of having a system that does not know the extension import sth as operational that isnt. This pattern was carried on into the opertionalTrainSection, the operationalTrainSectionPart as well as to its commercial counterparts.

Best regards, Milan

Milan Hoffmann – Timetable schema coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Previous Topic: [railML3] Use of @next= to link operationalTrainParts into a sequence
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Thu Jul 16 22:05:04 CEST 2026