TT:operationalTrain

From railML 3 Wiki
Jump to navigation Jump to search

Introduction

Documentation

Syntax

Autoexport from the XML-Schema for element TT:operationalTrain of railML® version 3.3
Documentation An operational train groups one or many variants of the same operational train, so trains that run with the same basic train number but with differences between each other. Operational trains encode an operational view of the train, so a view a IM would have on a train.
Subschema timetable
Parents* operationalTrains
Children name (0..*), operationalTrainVariant (1..*)
Attributes:
  • 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:operationalTrain of railML® version 3.2
Documentation An operational train groups one or many variants of the same operational train, so trains that run with the same basic train number but with differences between each other. Operational trains encode an operational view of the train, so a view a IM would have on a train.
Subschema timetable
Parents* operationalTrains
Children name (0..*), operationalTrainVariant (1..*)
Attributes:
  • 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 attributes have been changed.

Semantics

Best Practice / Examples

For this example it is assumed that the reader is familiar with the concept of <itinerary> of railML3. The conceptual difference between <itinerary> and <operationalTrain> or <commercialTrain> is a reference to the Rollingstock and further movement in time with @offset if needed.

Reusing itineraries

Below is an example of three trains based on the same <itinerary>. Analogously to the approach of railML3 in which <itinerary> is based on <baseItinerary>, <operationalTrain>s and <commercialTrain>s are based on <itinerary>.

      <operationalTrain id="ot-1">
        <operationalTrainVariant id="ov-1" itineraryRef="it-1" validityRef="va-2">
          <identifiers>
            <identifier number="OT1066" type="OperationalTrainNumber"/>
          </identifiers>
          <operationalTrainSection>
            <operationalTrainSectionPart id="os-1">
              <formationInformation formationRef="fm-1"/>
            </operationalTrainSectionPart>
          </operationalTrainSection>
        </operationalTrainVariant>
      </operationalTrain>
      <operationalTrain id="ot-2">
        <operationalTrainVariant id="ov-2" itineraryRef="it-1" offset="PT1H" validityRef="va-2">
          <identifiers>
            <identifier number="OT1067" type="OperationalTrainNumber"/>
          </identifiers>
          <operationalTrainSection>
            <operationalTrainSectionPart id="os-2">
              <formationInformation formationRef="fm-1"/>
            </operationalTrainSectionPart>
          </operationalTrainSection>
        </operationalTrainVariant>
      </operationalTrain>
      <operationalTrain id="ot-3">
        <operationalTrainVariant id="ov-3" itineraryRef="it-1" offset="PT2H" validityRef="va-2">
          <identifiers>
            <identifier number="OT1068" type="OperationalTrainNumber"/>
          </identifiers>
          <operationalTrainSection>
            <operationalTrainSectionPart id="os-3">
              <formationInformation formationRef="fm-1"/>
            </operationalTrainSectionPart>
          </operationalTrainSection>
        </operationalTrainVariant>
      </operationalTrain>

This example demonstrates that it is valid to base two or more trains on the same <itinerary>.

This way railML3 approach helps to reduce the redundancy in code. Even though users can define a set of itineraries specifically for all trains "ot-1", "ot-2" and "ot-3", the best practice of railML3 is to reuse the existing itineraries as much as possible moving them in time with @offset attribute if needed.


Additional Information

Notes

Be aware of semantic constraint TT:002.

Open Issues