TT:operationalTrainSectionPart

From railML 3 Wiki
Jump to navigation Jump to search

Introduction

Documentation

Syntax

Autoexport from the XML-Schema for element TT:operationalTrainSectionPart of railML® version 3.3
Documentation The operational train section parts provide information about parts of the train, i. e. a number of coaches and engines.
Subschema timetable
Parents* operationalTrainSection
Children additionalStopInfos (0..1), equipmentInformation (0..1), formationInformation (0..1), isOnRequest (0..1)
Attributes:
  • categoryRef: The category refers to a single operationalTrainSectionPart. The reference can be used, for example, if coupled trains require different categories or to identify empty operationalTrainSectionParts with different categories. (optional; xs:IDREF),

  • next: Reference to the next operational train section part. The next operational train section part would typically reside in another operational train section, not necessarily of the same operational train variant. Like this the splitting or coupling of trains can be modelled. (optional; xs:IDREF),

  • operatorRef: Allows referencing the operator of the part of the train (optional; xs:IDREF),

  • sequenceNumber: allows specifying the order of the individual operational train section parts in the train. When sorting ascending the first operational train section part describes the part of the train that is at the front. (obligatory; xs:unsignedInt),

  • isEmpty: Trains marked with this flag are running empty and thus can be treated differently when rescheduling and dispatching. (optional; xs:boolean),

  • isPublic: Unless specified otherwise, all trains are considered public.
    Non-public trains, their schedules and other details must not be communicated to the open public. (optional; xs:boolean),

  • trainType: Allows classification of trains using an extendable enumeration. Mainly used to distinguish between passenger and freight trains. (optional; xs:string; patterns: other:w{2,})
Possible values:
  • EngineRun: Indicates that the train consists of a locomotive only
  • Goods: Indicates that the train is a freight train
  • Passenger: Indicates that the train is a passenger train,

  • id: the identifier of the object; this can be either of type xs:ID or UUID (obligatory; xs:ID); compare: Dev:Identities
*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.


 

Autoexport from the XML-Schema for element TT:operationalTrainSectionPart of railML® version 3.2
Documentation The operational train section parts provide information about parts of the train, i. e. a number of coaches and engines.
Subschema timetable
Parents* operationalTrainSection
Children additionalStopInfos (0..1), formationInformation (0..1), isOnRequest (0..1)
Attributes:
  • categoryRef: The category refers to a single operationalTrainSectionPart. The reference can be used, for example, if coupled trains require different categories or to identify empty operationalTrainSectionParts with different categories. (optional; 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}}),

  • next: Reference to the next operational train section part. The next operational train section part would typically reside in another operational train section, not necessarily of the same operational train variant. Like this the splitting or coupling of trains can be modelled. (optional; 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 part of the train (optional; 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}}),

  • isEmpty: Trains marked with this flag are running empty and thus can be treated differently when rescheduling and dispatching. (optional; xs:boolean),

  • isPublic: Unless specified otherwise, all trains are considered public.
    Non-public trains, their schedules and other details must not be communicated to the open public. (optional; xs:boolean),

  • trainType: Allows classification of trains using an extendable enumeration. Mainly used to distinguish between passenger and freight trains. (optional; xs:string; patterns: other:w{2,})
Possible values:
  • EngineRun
  • Goods
  • Passenger,

  • id: unique identifier (obligatory; 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}}); compare: Dev:Identities
*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.


 

This element does not appear in railML® 3.1 within the TT subschema. It is available only in railML® 3.2. Do not hesitate to contact railML.org 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 children have been changed.

The attributes have been changed.

Semantics

Private-cloud-icon.png Semantic Constraint "TT:001":
 
The next attribute shall reference an <operationalTrainSectionPart> that is not referenced by any other next-reference. In other words: Within the chain of <operationalTrainSectionPart>s linked by the attribute next, there can be no element that has more than one predecessor. The @next reference must establish a one to one relationship between two <operationalTrainSectionPart>s.
 
Proposed on September 15th 2022
Approved on October 13th 2022
FIXME: add Link to discussion!
Please, recognize our guidelines on semantic constraints

Best Practice / Examples

Additional Information

Notes

The semantic constraint TT:001 was added in order to make sure that the evaluation of <operationalTrainSectionPart>s remains easy. If a train is operating differently on selected operating days this should be modelled by using different <operationalTrainVariant>s even if the change is limited to a certain part of the trains route.

Open Issues