TT:operationalTrainSection

Documentation

Syntax

3.33.23.1

Autoexport from the XML-Schema for element TT:operationalTrainSection of railML® version 3.3      UML-visualization of TT
Description	info about a part of the operational trains path
Subschema	timetable
Parents*	operationalTrainVariant
Children**	range (0..1), isCancelled (0..1), isOnRequest (0..1), additionalStopInfos (0..1), operationalTrainSectionPart (1..*)
Attributes: categoryRef: Allows assigning a category to the train. The category refers to all operationalTrainSectionParts running coupled on this section. The referenced category is therefore often assigned by the infrastructureManager. (optional: tRef : xs:IDREF), operatorRef: Allows referencing the operator of the train (optional: tRef : xs:IDREF), sequenceNumber: Used to explicitly specify the order of operationalTrainSections of the enclosing operationalTrainVariant by providing ascending sequence numbers. (obligatory: xs:unsignedInt : xs:unsignedInt), slotHolderRef: Allows referencing the organizational unit holding the slot of the train (optional: tRef : xs:IDREF)
*Notice: Elements may have different parent elements. As a consequence they may be used in different contexts. Please, consider this as well as a user of this Wiki as when developing this documentation further. Aspects that are only relevant with respect to one of several parents should be explained exclusively in the documentation of the respective parent element. **Notice: To learn, how to interpret multiplicity information like (0..*) go to The W3C Recommendation on XML Schema

Autoexport from the XML-Schema for element TT:operationalTrainSection of railML® version 3.2      UML-visualization of TT
Description	The operational train sections of an operational train variant provide info about a part of the trains path.
Subschema	timetable
Parents*	operationalTrainVariant
Children**	range (0..1), isCancelled (0..1), isOnRequest (0..1), additionalStopInfos (0..1), operationalTrainSectionPart (1..*)
Attributes: categoryRef: Allows assigning a category to the train. The category refers to all operationalTrainSectionParts running coupled on this section. The referenced category is therefore often assigned by the infrastructureManager. (optional: tRef : xs:string: patterns: (urn:uuid: )?[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|\{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}\}), operatorRef: Allows referencing the operator of the train (optional: tRef : xs:string: patterns: (urn:uuid: )?[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|\{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}\}), slotHolderRef: Allows referencing the organizational unit holding the slot of the train (optional: tRef : xs:string: patterns: (urn:uuid: )?[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|\{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}\})
*Notice: Elements may have different parent elements. As a consequence they may be used in different contexts. Please, consider this as well as a user of this Wiki as when developing this documentation further. Aspects that are only relevant with respect to one of several parents should be explained exclusively in the documentation of the respective parent element. **Notice: To learn, how to interpret multiplicity information like (0..*) go to The W3C Recommendation on XML Schema

This element does not appear in railML^® 3.1 within the TT subschema. It is available only in railML^® 3.2, 3.3. Do not hesitate to contact railML.org e.V. for further questions.

Changes 3.1→3.2

There exists an overview of all changes between railML^® 3.1 and railML^® 3.2 on page Dev:Changes/3.2.
Introduced with version 3.2.

Changes 3.2→3.3

There exists an overview of all changes between railML^® 3.2 and railML^® 3.3 on page Dev:Changes/3.3.

The element documentation has been changed.

The attributes have been changed.

Semantics

Semantic Constraint "TT:004":   The itinerary sections of an <operationalTrainVariant>, defined by the <operationalTrainSection>s and their respective <range>s, that are not <isCancelled> and not marked as <isOnRequest>, must be pairwise disjoint, except for their respective first and last <baseItineraryPoint>s.   Proposed on 12 January 2023 Approved on 9 March 2023 Semantic Constraints for Train Section (link to the railML® website). Please, recognize our guidelines on semantic constraints

Semantic Constraint "TT:005":   The first(last) <baseItineraryPoint> of each <operationalTrainSection> within an <operationalTrainVariant> must either be the referenced <itinerary>'s first(last) <baseItineraryPoint>, or coincide with another section's last(first) <baseItineraryPoint>.   Proposed on 12 January 2023 Approved on 9 March 2023 Semantic Constraints for Train Section (link to the railML® website)". Please, recognize our guidelines on semantic constraints

Semantic Constraint "TT:010":   In an <operationalTrainSection>, the <range> element's start and end must reference <baseItineraryPoint> elements such that their order aligns with the sequencing defined by the <itinerary>.   Proposed on 7 March 2025 Approved on 13 April 2026 Proposal for new semantic constraints and change of existing ones (link to the railML® website)". Please, recognize our guidelines on semantic constraints

Best Practice / Examples

TT:010

The semantic constraint TT:010 is supposed to make sure that the <operationalTrainSection>'s are organized in a way that does not causes inconsistencies, in particular jumps in time or loops.
The semantic constraint in particular means that if the start and end points belong to different <baseItinerary> elements, the <range> elements referencing these <baseItinerary>'s in the <itinerary> must have increasing @sequenceNumber. If both points belong to the same <baseItinerary>, their own @sequenceNumber must increase from start to end, unless the <baseItinerary> consists of only a single <baseItineraryPoint>.