Template:Table/Dev:Semantic Constraints: Difference between revisions

From railML 2 Wiki
Jump to navigation Jump to search
[checked revision][checked revision]
(+IDs)
No edit summary
 
(48 intermediate revisions by 5 users not shown)
Line 1: Line 1:
<noinclude>[[Dev:Semantic_Constraints|Return to article]]</noinclude>
<noinclude>[[Dev:Semantic_Constraints|Return to article]]{{interwiki}}</noinclude>
{|class="wikitable sortable"
{|class="wikitable sortable"
!Element
!Element
Line 6: Line 6:
!Date of acception
!Date of acception
!Date of deprecation
!Date of deprecation
!Description
|-
|-
|{{TT:Tag|timetablePeriod|ex=1}}
|{{TT:Tag|timetablePeriod|wiki=2|ex=1}}
|TT:1
|TT:001
|2018-11-12
|2018-11-12
|2019-03-21
|2019-03-21
|
|
|Any '''starting time stamp''' (as it may result e.g. from a combination of ''startDate'' and ''startTime'') shall be lower or equal any '''ending time stamp''' (e.g. ''endDate'') if both are given. Must not overlap with other validity periods.
|-
|-
|{{TT:Tag|specialService|operatingPeriodRef|ex=1}}
|{{TT:Tag|specialService|wiki=2|ex=1}}
|TT:1
|TT:018
|2018-11-12
|2018-11-12
|2019-03-21
|2019-03-21
|
|
|Any '''starting time stamp''' (as it may result e.g. from a combination of ''startDate'' and ''startTime'') shall be lower or equal any '''ending time stamp''' (e.g. ''endDate'') if both are given. Must not overlap with other {{TT:Tag|specialService}} validity periods of the same enclosing {{TT:Tag|operatingPeriod}}.
|-
|-
|{{TT:Tag|specialService|operatingPeriod|ex=1}}
|{{TT:Tag|operatingPeriodRef|trainPart|wiki=2|ex=1}}
|TT:1
|CO:002
|2018-11-12
|2018-11-12
|2019-03-21
|2019-03-21
|
|
|Any '''starting time stamp''' (as it may result e.g. from a combination of ''startDate'' and ''startTime'') shall be lower or equal any '''ending time stamp''' (e.g. ''endDate'') if both are given.
|-
|-
|{{TT:Tag|operatingPeriodRef|trainPart|ex=1}}
|{{TT:Tag|operatingPeriod|wiki=2|ex=1}}
|TT:1
|CO:002
|2018-11-12
|2018-11-12
|2019-03-21
|2019-03-21
|
|
|Any '''starting time stamp''' (as it may result e.g. from a combination of ''startDate'' and ''startTime'') shall be lower or equal any '''ending time stamp''' (e.g. ''endDate'') if both are given.
|-
|-
|{{TT:Tag|operatingPeriod|ex=1}}
|{{TT:Tag|operatingDay|wiki=2|ex=1}}
|TT:1
|TT:019
|2018-11-12
|2018-11-12
|2019-03-21
|2019-03-21
|
|
|Any '''starting time stamp''' (as it may result e.g. from a combination of ''startDate'' and ''startTime'') shall be lower or equal any '''ending time stamp''' (e.g. ''endDate'') if both are given. Must not overlap with other {{TT:Tag|operatingDay}} validity periods of the same enclosing {{TT:Tag|operatingPeriod}}.
|-
|-
|{{TT:Tag|operatingDay|ex=1}}
|{{TT:Tag|circulation|wiki=2|ex=1}}
|TT:1
|CO:002
|2018-11-12
|2018-11-12
|2019-03-21
|2019-03-21
|
|
|Any '''starting time stamp''' (as it may result e.g. from a combination of ''startDate'' and ''startTime'') shall be lower or equal any '''ending time stamp''' (e.g. ''endDate'') if both are given.
|-
|-
|{{TT:Tag|ocpTT|ex=1}} (first semantic constraint)
|{{TT:Tag|blockPart|wiki=2|ex=1}}
|TT:2
|CO:002
|2018-10-25
|2018-11-12
|2019-06-20
|2019-03-21
|
|
|Any '''starting time stamp''' (as it may result e.g. from a combination of ''startDate'' and ''startTime'') shall be lower or equal any '''ending time stamp''' (e.g. ''endDate'') if both are given.
|-
|-
|{{TT:Tag|ocpTT|ex=1}} (second semantic constraint)
|{{Tag|rs|designator|wiki=2|ex=1}} {{intro|2.5}}
|
|RS:001
|2018-10-25
|2018-11-12
|discarded
|2019-03-21
|
|
|Any '''starting time stamp''' (as it may result e.g. from a combination of ''startDate'' and ''startTime'') shall be lower or equal any '''ending time stamp''' (e.g. ''endDate'') if both are given. Must not overlap with the validity periods of other entries of the same {{Attr|register}} of the same enclosing {{RS:Tag|state}}.
|-
|-
|{{TT:Tag|circulation|ex=1}}
|{{RS:Tag|operator|wiki=2|ex=1}}
|TT:1
|RS:002
|2018-11-12
|2018-11-12
|2019-03-21
|2019-03-21
|
|
|Any '''starting time stamp''' (as it may result e.g. from a combination of ''startDate'' and ''startTime'') shall be lower or equal any '''ending time stamp''' (e.g. ''endDate'') if both are given. Must not overlap with other {{RS:Tag|operator}} validity periods of the same enclosing {{RS:Tag|vehicle}}/{{RS:Tag|classification}}.
|-
|-
|{{TT:Tag|blockPart|ex=1}} (first semantic constraint)
|{{RS:Tag|owner|wiki=2|ex=1}}&#32;{{intro|2.5}}
|TT:1
|RS:003
|2018-11-12
|2018-11-12
|2019-03-21
|2019-03-21
|
|
|Any '''starting time stamp''' (as it may result e.g. from a combination of ''startDate'' and ''startTime'') shall be lower or equal any '''ending time stamp''' (e.g. ''endDate'') if both are given. Must not overlap with other {{RS:Tag|owner}} validity periods of the same enclosing {{RS:Tag|vehicle}}/{{RS:Tag|classification}}.
|-
|-
|{{TT:Tag|blockPart|ex=1}} (second semantic constraint)
|{{Tag|RS|state|wiki=2|ex=1}}
|TT:3
|RS:004
|2019-07-13
|2018-11-12
|
|2019-03-21
|
|
|Any '''starting time stamp''' (as it may result e.g. from a combination of ''startDate'' and ''startTime'') shall be lower or equal any '''ending time stamp''' (e.g. ''endDate'') if both are given. Must not overlap with other {{RS:Tag|state}} validity periods of the same enclosing {{RS:Tag|vehicle}}/{{RS:Tag|states}}.
|-
|-
|{{TT:Tag|blockPart|ex=1}} (third semantic constraint)
|{{IS:Tag|state|wiki=2|ex=1}}
|TT:4
|IS:020
|2019-07-20
|2018-11-12
|
|2019-03-21
|
|
|Any '''starting time stamp''' (as it may result e.g. from a combination of ''startDate'' and ''startTime'') shall be lower or equal any '''ending time stamp''' (e.g. ''endDate'') if both are given. Must not overlap with other {{IS:Tag|state}} validity periods of the same enclosing {{IS:Tag|states}} collection. See also https://wiki2.railml.org/wiki/Dev:Defining_temporal_availability_of_infrastructure_elements_and_speed_profiles
|-
|-
|{{RS:Tag|operator|ex=1}}
|{{IS:Tag|state (with length)|wiki=2|ex=1}}
|TT:1
|IS:021
|2018-11-12
|2018-11-12
|2019-03-21
|2019-03-21
|
|
|Any '''starting time stamp''' (as it may result e.g. from a combination of ''startDate'' and ''startTime'') shall be lower or equal any '''ending time stamp''' (e.g. ''endDate'') if both are given. Must not overlap with other {{IS:Tag|state (with length)}} validity periods of the same enclosing {{IS:Tag|states (with length)}} collection. See also https://wiki2.railml.org/wiki/Dev:Defining_temporal_availability_of_infrastructure_elements_and_speed_profiles
|-
|-
|{{IS:Tag|state|ex=1}}
|{{IS:Tag|designator|wiki=2|ex=1}}
|TT:1
|CO:001
|2018-11-12
|2018-11-12
|2019-03-21
|2019-03-21
|
|
|Any '''starting time stamp''' (as it may result e.g. from a combination of ''startDate'' and ''startTime'') shall be lower or equal any '''ending time stamp''' (e.g. ''endDate'') if both are given. Must not overlap with the validity periods of other entries of the same {{Attr|register}} of the same enclosing element.
|-
|-
|{{IS:Tag|state (with length)|ex=1}}
|{{Tag|co|designator|wiki=2|ex=1}} {{intro|2.5}}
|TT:1
|CO:001
|2018-11-12
|2018-11-12
|2019-03-21
|2019-03-21
|
|
|Any '''starting time stamp''' (as it may result e.g. from a combination of ''startDate'' and ''startTime'') shall be lower or equal any '''ending time stamp''' (e.g. ''endDate'') if both are given. Must not overlap with the validity periods of other entries of the same {{Attr|register}} of the same enclosing element.
|-
|-
|{{IS:Tag|designator|ex=1}}
|{{Tag|co|phase|wiki=2|ex=1}} {{intro|2.5}}
|TT:1
|CO:002
|2018-11-12
|2018-11-12
|2019-03-21
|2019-03-21
|
|
|Any '''starting time stamp''' (as it may result e.g. from a combination of ''startDate'' and ''startTime'') shall be lower or equal any '''ending time stamp''' (e.g. ''endDate'') if both are given.
|-
|{{TT:Tag|ocpTT|wiki=2|ex=1}}
|TT:002
|2018-10-25
|2019-06-20
|
|The attribute sequence is shall be increasing according to the train path.
|-
|<s>{{TT:Tag|ocpTT|wiki=2|ex=1}}</s>
|
|2018-10-25
|''discarded''
|
|<s>No {{attr|ocpRef}} is allowed to occur more than one time in the same {{TT:Tag|trainPart}}</s>
|-
|-
|{{IS:Tag|speedChange|ex=1}}
|{{TT:Tag|blockPart|wiki=2|ex=1}}
|IS:1
|TT:003
|2019-04-11
|2019-07-13
|2019-07-18
|
|
|By means of a {{TT:Tag|blockPart}} it is possible to model both journeys with and without reference to a {{TT:Tag|trainPart}} within a roster, as well as services without change of location (without reference to a {{TT:Tag|trainPart}}). These 3 basic types are distinguished by the attribute {{Attr|mission}}. The following table presents the semantic constraints: ''(not included here)''
|-
|{{TT:Tag|blockPart|wiki=2|ex=1}}
|TT:004
|2019-07-20
|2019-07-18
|
|
|{{Attr|vehicleRef}} and {{Attr|formationRef}} shall not be used within the same blockPart, since a blockPart is either one for a certain vehicle or one for a whole formation.
|-
|-
|{{TT:Tag|rostering|ex=1}}
|{{TT:Tag|rostering|wiki=2|ex=1}}
|TT:5
|TT:005
|2019-05-22
|2019-05-22
|2019-06-25
|2019-06-25
|
|
|{{Attr|vehicleRef}} and {{Attr|formationRef}} are to be used exceptional since the circulation plan is either one for a certain vehicle or one for a whole formation.
|-
|-
|{{TT:Tag|stopDescription|ex=1}} (first semantic constraint)
|{{TT:Tag|stopDescription|wiki=2|ex=1}}
|TT:6
|TT:006
|2018-09-03
|2018-09-03
|2019-06-20
|2019-06-20
|
|
|Constraints between the attributes {{TT:Tag|ocpTT}}.{{Attr|ocpType}}, {{TT:Tag|stopDescription}}.{{Attr|guaranteedPass}}, .{{Attr|commercial}}, .{{Attr|onOff}}, .{{Attr|stopOnRequest}} and  .{{Attr|operationalStopOrdered}}
|-
|-
|{{TT:Tag|stopDescription|ex=1}} (second semantic constraint)
|<s>''{{TT:Tag|stopDescription|wiki=2|ex=1}} (Stop on request / More than one stop type per OCP)''</s>
|TT:7
|''TT:007''
|2019-06-19
|''2019-06-19''
|
|''discarded''
|''2020-04-23''
|
|
|-
|-
|{{TT:Tag|trackInfo|ex=1}} (first semantic constraint)
|{{TT:Tag|trackInfo|wiki=2|ex=1}}
|TT:8
|TT:008
|2018-08-21
|2018-08-21
|2019-06-20
|2019-06-20
|
|
|The representation of differentiated track usage must not result in differences in arrival and departure times. In these cases, a separate {{TT:Tag|trainPart}} / {{TT:Tag|train}} with different arrival and departure times must be created.
|-
|-
|{{TT:Tag|trackInfo|ex=1}} (second semantic constraint)
|{{TT:Tag|trackInfo|wiki=2|ex=1}}
|TT:9
|TT:009
|2018-08-21
|2018-08-21
|2019-06-20
|2019-06-20
|
|
|The operating days days of the {{TT:Tag|operatingPeriodRef}}s of the individual {{TT:Tag|trackInfo}} entries must be disjoint and must not contain more traffic days than the parent {{TT:Tag|trainPart}}. If fewer traffic days are provided in the {{TT:Tag|trackInfo}} entries than the parent {{TT:Tag|trainPart}} contains, the information (e.g. attribute {{Attr|trackInfo}}) of the parent {{TT:Tag|ocpTT}} must be evaluated for these operating days.
|-
|{{TT:Tag|times|wiki=2|ex=1|semcon=TT:010}} ''(Correct encoding of run time supplements)''
|TT:010
|2019-06-19
|2020-10-15
|
|{{@|scope}}&#61;'earliest' and 'latest' are ''not'' intended to encode supplement times, as this is redundant to <ocpTT>.<sectionTT>.<runTimes>@operationalReserve, @additionalReserve, @minimalTime.
|-
|{{TT:Tag|times|wiki=2|ex=1|semcon=TT:011}}
|TT:011
|2019-06-19
|[[special:diff/13391/13393|''discarded'']]
|
|
|-
|{{TT:Tag|times|wiki=2|ex=1|semcon=TT:012}}
|TT:012
|2019-06-19
|2022-06-02
|
|When {{@|scope}}&#61;'actual' is used, then the operating period and/or timetable period specified at the trainpart level shall refer to only one operating day. Like this the operating day to which the actual times refer is defined.
|-
|{{TT:Tag|times|wiki=2|ex=1|semcon=TT:013}}
|TT:013
|2019-06-19
|[[special:diff/13361/13362|''discarded'']]
|
|
|-
|{{TT:Tag|times|wiki=2|ex=1|semcon=TT:014}} ''(Arrival times for passing OCP's)''
|TT:014
|2019-06-19
|2022-06-02
|
|{{@|arrival}} is not to be specified if the attribute {{Attr|ocpType}} of the parent {{TT:Tag|ocpTT}} has the value ''pass'' - use {{Attr|departure}} for run-through (passing) times; This is in line with the definition of {{@|arrival}} as the moment at which the train ends its movement and gets to a halt at the parent {{tag|TT|ocpTT}}.
|-
|{{TT:Tag|times|wiki=2|ex=1|semcon=TT:015}} ''(Arrival time at first OCP)''
|TT:015
|2019-06-19
|2022-06-02
|
|At the first {{TT:Tag|ocpTT}} of a {{TT:Tag|trainPart}} that is not the first one of the {{TT:Tag|trainPartSequence}}, the attribute {{@|arrival}} is optional. If it is set anyway, then, for consistency reasons, the value of {{@|arrival}} of the regarding {{TT:Tag|ocpTT}} must be identical for both this {{TT:Tag|trainPart}} and the preceding one.
|-
|{{TT:Tag|times|wiki=2|ex=1|semcon=TT:016}} ''(Departure time at last OCP)''
|TT:016
|2020-10-09
|2022-06-02
|
|At the last {{TT:Tag|ocpTT}} of a {{TT:Tag|trainPart}} that is not the last one of the {{TT:Tag|trainPartSequence}}, the attribute {{@|departure}} is optional. If it is set anyway, then, for consistency reasons, the value of {{@|departure}} of the regarding {{TT:Tag|ocpTT}} must be identical for both this {{TT:Tag|trainPart}} and the subsequent one.
|-
|{{tag|tt|connection|wiki=2|ex=1|semcon=TT:017}}
|TT:017
|2022-12-15
|2022-12-15
|
|If the trainPartRef attribute is given, then there must also be a trainRef attribute, and the trainPartRef attribute must point to a train part of the train referenced by the trainRef attribute.
|-
|<s>{{IS:Tag|speedChange|wiki=2|ex=1}}</s>
|IS:001
|2019-04-11
|''discarded''
|
|<s>Always define {{Attr|trainRelation}}</s>
|-
|{{IS:Tag|trackEnd|wiki=2|ex=1}}
|IS:002
|2019-06-17
|
|
|
*The value of {{@|pos}} in {{IS:Tag|trackBegin|attr=pos}} is always the lowest value of all specified {{IS:Tag|trackElements}} and {{IS:Tag|ocsElements}}. It is always lower (or equal if length = 0) than the value of {{@|pos}} of {{IS:Tag|trackEnd|attr=pos}}.
*The value of {{@|pos}} in {{IS:Tag|trackEnd|attr=pos}} is always the highest value of all specified {{IS:Tag|trackElements}} and {{IS:Tag|ocsElements}}. It is always higher (or equal if length = 0) than the value of {{@|pos}} of {{IS:Tag|trackBegin|attr=pos}}.
*Subtracting the value of {{@|pos}} in {{IS:Tag|trackBegin|attr=pos}} from the value of {{@|pos}} in {{IS:Tag|trackEnd|attr=pos}} will result in the length of the enclosing {{IS:Tag|track}}.
*If two {{IS:Tag|track}}s are connected, the {{@|absPos}} values of the connected {{IS:Tag|trackBegin|attr=absPos}} and {{IS:Tag|trackEnd|attr=absPos}} must be identical '''if'''
**both are provided and
**no {{IS:Tag|mileageChange}} is defined at this point and
**both {{IS:Tag|track}}s belong to the same mileage system.
|-
|{{IS:Tag|trackBegin|wiki=2|ex=1}}
|IS:003
|2019-06-17
|
|
|
*The value of {{@|pos}} in {{IS:Tag|trackBegin|attr=pos}} is always the lowest value of all specified {{IS:Tag|trackElements}} and {{IS:Tag|ocsElements}}. It is always lower (or equal if length = 0) than the value of {{@|pos}} of {{IS:Tag|trackEnd|attr=pos}}.
*The value of {{@|pos}} in {{IS:Tag|trackEnd|attr=pos}} is always the highest value of all specified {{IS:Tag|trackElements}} and {{IS:Tag|ocsElements}}. It is always higher (or equal if length = 0) than the value of {{@|pos}} of {{IS:Tag|trackBegin|attr=pos}}.
*Subtracting the value of {{@|pos}} in {{IS:Tag|trackBegin|attr=pos}} from the value of {{@|pos}} in {{IS:Tag|trackEnd|attr=pos}} will result in the length of the enclosing {{IS:Tag|track}}.
*If two {{IS:Tag|track}}s are connected, the {{@|absPos}} values of the connected {{IS:Tag|trackBegin|attr=absPos}} and {{IS:Tag|trackEnd|attr=absPos}} must be identical '''if'''
**both are provided and
**no {{IS:Tag|mileageChange}} is defined at this point and
**both {{IS:Tag|track}}s belong to the same mileage system.
|-
|{{IS:Tag|track|wiki=2|ex=1}}
|IS:004
|2019-06-17
|
|
|Single track railway lines shall have main driving direction {{@|mainDir}}&#61;"none" if they are used in both directions
|-
|{{IS:Tag|ocp|wiki=2|ex=1}}
|IS:005
|2019-06-19
|2022-07-14
|
|An {{tag|IS|ocp}} that refers to a parent {{tag|IS|ocp}} via an {{@|parentOcpRef}} overwrites the attributes and elements of the parent {{tag|IS|ocp}} if explicitely defined. If an element is specified on an {{IS:Tag|ocp}} that uses a {{@|parentOcpRef}} any information provided with that element on a higher layer of the {{IS:Tag|ocp}}-tree is overwritten. There is no merging of element-information from different levels. The same applies for attributes of {{IS:Tag|ocp}}.
|-
|{{IS:Tag|mileageChange|wiki=2|ex=1}}
|IS:006
|2019-06-19
|
|
|
*Define attributes {{@|absPosIn}} and {{@|absPos}} for "real" mileage changes
*Define attribute {{@|absPosIn}} alone in case of an ending mileage
*Define attribute {{@|absPos}} alone in case of a starting mileage
*For starting mileages and "real" mileage changes, the {{@|absDir}} has to be fiven to define the ongoing orientation of the mileage
|-
|<s>{{IS:Tag|propOperational|wiki=2|ex=1}}</s>
|IS:007
|2020-02-25
|''discarded''
|
|
|-
|{{IS:Tag|uptime|attr=IS:008|wiki=2|ex=1}}
|IS:008
|2020-02-28
|
|
|An {{Tag|IS|ocp|attr=operationalType}} with {{Tag|IS|propOperational|@=operationalType}}=''blockSignal'' shall not have
{{@|mode}}=''manned'' (as a manned ''blockSignal'' shall be modelled in {{rml|2.x}} as a ''blockPost'').
|-
|{{IS:Tag|uptime|attr=IS:009|wiki=2|ex=1}}
|IS:009
|2020-02-28
|
|
|An {{Tag|IS|ocp}} with attribute {{Tag|IS|propOperational|@=operationalType}}=''stoppingPoint'' shall not have {{@|mode}}=''manned'' (as a ''stoppingPoint'' has no operational usage and therefore no operational staff by the IM).
|-
|{{IS:Tag|uptime|attr=IS:010|wiki=2|ex=1}}
|IS:010
|2020-02-28
|
|
|An enumeration of several time periods by {{@|from}} and {{@|until}} for one {{Tag|IS|ocp}} shall not overlap so that for every time there shall be a unique status of {{Tag|IS|uptime}}.
|-
|{{IS:Tag|speedChange|wiki=2|ex=1|semcon=IS:011}}
|IS:011
|2022-03-14 (to be def. more accurately)
|2021-11-10 (40th conference slide 11)
|
|
*Every {{tag|is|track}} has to have at least one {{tag|is|speedChange}} at the track begin with parameters {{@|pos}}="0" and {{@|dir}}="up".
*Every {{tag|is|track}} has to have at least one {{tag|is|speedChange}} at the track end with parameters {{@|pos}}="{value equal to trackEnd@pos}" and {{@|dir}}="down".
|-
|{{IS:Tag|speedProfile|wiki=2|ex=1|semcon=IS:012}}
|IS:012
|2022-03-14
|
|
|{{@|basicSpeedProfile}} is always linked with {{@|influence}}={{enum|increasing}}
|-
|{{IS:Tag|speedProfile|wiki=2|ex=1|semcon=IS:013}}
|IS:013
|2022-03-14
|
|
|
*{{@|influence}}={{enum|increasing}}: The {{tag|is|speedProfile}} increases the permitted speed. If multiple "increasing" speed profiles are applicable, select the one with the highest {{@|vMax}} value.
*{{@|influence}}={{enum|decreasing}}: The {{tag|is|speedProfile}} decreases the permitted speed. If multiple "decreasing" speed profiles are applicable, select the one with the lowest {{@|vMax}} value. If this value is lower than the speed of an "increasing" speed profile, it overrides that speed.
|-
|{{IS:Tag|tunnel|wiki=2|ex=1|semcon=IS:014}}
|IS:014
|2022-03-14
|
|
|Define the tunnel resistance factor {{@|resistanceFactorPassenger|IS:tunnel}} resp. {{@|resistanceFactorFreight|IS:tunnel}} only if {{@|kind}} and {{@|crossSection}} are not known.
|-
|{{IS:Tag|ocp|wiki=2|ex=1|semcon=IS:015}}
|IS:015
|2022-07-14
|2022-08-11
|
|When specifying {{@|parentOcpRef}} for an {{IS:Tag|ocp}} circles are not allowed. That means that when following the chain of {{@|parentOcpRef}} no {{IS:Tag|ocp}} shall be visited twice.
|-
|{{IS:Tag|axleWeightChange|wiki=2|ex=1|semcon=IS:016}} {{IS:Tag|clearanceGaugeChange}} {{IS:Tag|electrificationChange}} {{IS:Tag|gaugeChange}} {{IS:Tag|ownerChange}} {{IS:Tag|gradientChange}} {{IS:Tag|powerTransmissionChange}} {{IS:Tag|radiusChange}}
|IS:016
|2021-11-10
|2021-11-10
|
|must not have @dir attribute according to {{site|https://www.railml.org/en/event-reader/40th-railml-conference-gothenburg.html|Report from the Infrastructure developers in railML 3.2 and 2.5}} slide 9 and {{ticket|357|2}}
|-
|{{CO:Tag|railml|wiki=2|ex=1|semcon=IS:017}} {{IS:Tag|infrastructure}}
|IS:017
|2024-03-25
|2021-03-25
|
|either {{IS:Tag|infrastructure}} or {{CO:Tag|railml}} must have @version attribute
|-
|{{CO:Tag|metadata|wiki=2|ex=1|semcon=IS:018}} @name
|IS:018
|2024-03-25
|2021-03-25
|
|either {{CO:Tag|metadata}} must have {{CO:Tag|dc:language}} child or every @name attribute accompanied by @xml:lang
|-
|{{IS:Tag|gradientChange|wiki=2|ex=1|semcon=IS:019}}
|IS:019
|2024-03-25
|2021-03-25
|
|there can be no two {{IS:Tag|gradientChange}} belonging to the same track with the same @pos attribute
|}
|}

Latest revision as of 14:06, 14 May 2024

Return to article

Element ID Proposal date Date of acception Date of deprecation Description
<TT:timetablePeriod> TT:001 2018-11-12 2019-03-21 Any starting time stamp (as it may result e.g. from a combination of startDate and startTime) shall be lower or equal any ending time stamp (e.g. endDate) if both are given. Must not overlap with other validity periods.
<TT:specialService> TT:018 2018-11-12 2019-03-21 Any starting time stamp (as it may result e.g. from a combination of startDate and startTime) shall be lower or equal any ending time stamp (e.g. endDate) if both are given. Must not overlap with other <specialService> validity periods of the same enclosing <operatingPeriod>.
<TT:operatingPeriodRef> CO:002 2018-11-12 2019-03-21 Any starting time stamp (as it may result e.g. from a combination of startDate and startTime) shall be lower or equal any ending time stamp (e.g. endDate) if both are given.
<TT:operatingPeriod> CO:002 2018-11-12 2019-03-21 Any starting time stamp (as it may result e.g. from a combination of startDate and startTime) shall be lower or equal any ending time stamp (e.g. endDate) if both are given.
<TT:operatingDay> TT:019 2018-11-12 2019-03-21 Any starting time stamp (as it may result e.g. from a combination of startDate and startTime) shall be lower or equal any ending time stamp (e.g. endDate) if both are given. Must not overlap with other <operatingDay> validity periods of the same enclosing <operatingPeriod>.
<TT:circulation> CO:002 2018-11-12 2019-03-21 Any starting time stamp (as it may result e.g. from a combination of startDate and startTime) shall be lower or equal any ending time stamp (e.g. endDate) if both are given.
<TT:blockPart> CO:002 2018-11-12 2019-03-21 Any starting time stamp (as it may result e.g. from a combination of startDate and startTime) shall be lower or equal any ending time stamp (e.g. endDate) if both are given.
<RS:designator> (introduced with version 2.5) RS:001 2018-11-12 2019-03-21 Any starting time stamp (as it may result e.g. from a combination of startDate and startTime) shall be lower or equal any ending time stamp (e.g. endDate) if both are given. Must not overlap with the validity periods of other entries of the same register of the same enclosing <state>.
<RS:operator> RS:002 2018-11-12 2019-03-21 Any starting time stamp (as it may result e.g. from a combination of startDate and startTime) shall be lower or equal any ending time stamp (e.g. endDate) if both are given. Must not overlap with other <operator> validity periods of the same enclosing <vehicle>/<classification>.
<RS:owner> (introduced with version 2.5) RS:003 2018-11-12 2019-03-21 Any starting time stamp (as it may result e.g. from a combination of startDate and startTime) shall be lower or equal any ending time stamp (e.g. endDate) if both are given. Must not overlap with other <owner> validity periods of the same enclosing <vehicle>/<classification>.
<RS:state> RS:004 2018-11-12 2019-03-21 Any starting time stamp (as it may result e.g. from a combination of startDate and startTime) shall be lower or equal any ending time stamp (e.g. endDate) if both are given. Must not overlap with other <state> validity periods of the same enclosing <vehicle>/<states>.
<IS:state> IS:020 2018-11-12 2019-03-21 Any starting time stamp (as it may result e.g. from a combination of startDate and startTime) shall be lower or equal any ending time stamp (e.g. endDate) if both are given. Must not overlap with other <state> validity periods of the same enclosing <states> collection. See also https://wiki2.railml.org/wiki/Dev:Defining_temporal_availability_of_infrastructure_elements_and_speed_profiles
<IS:state (with length)> IS:021 2018-11-12 2019-03-21 Any starting time stamp (as it may result e.g. from a combination of startDate and startTime) shall be lower or equal any ending time stamp (e.g. endDate) if both are given. Must not overlap with other <state (with length)> validity periods of the same enclosing <states (with length)> collection. See also https://wiki2.railml.org/wiki/Dev:Defining_temporal_availability_of_infrastructure_elements_and_speed_profiles
<IS:designator> CO:001 2018-11-12 2019-03-21 Any starting time stamp (as it may result e.g. from a combination of startDate and startTime) shall be lower or equal any ending time stamp (e.g. endDate) if both are given. Must not overlap with the validity periods of other entries of the same register of the same enclosing element.
<CO:designator> (introduced with version 2.5) CO:001 2018-11-12 2019-03-21 Any starting time stamp (as it may result e.g. from a combination of startDate and startTime) shall be lower or equal any ending time stamp (e.g. endDate) if both are given. Must not overlap with the validity periods of other entries of the same register of the same enclosing element.
<CO:phase> (introduced with version 2.5) CO:002 2018-11-12 2019-03-21 Any starting time stamp (as it may result e.g. from a combination of startDate and startTime) shall be lower or equal any ending time stamp (e.g. endDate) if both are given.
<TT:ocpTT> TT:002 2018-10-25 2019-06-20 The attribute sequence is shall be increasing according to the train path.
<TT:ocpTT> 2018-10-25 discarded No ocpRef is allowed to occur more than one time in the same <trainPart>
<TT:blockPart> TT:003 2019-07-13 2019-07-18 By means of a <blockPart> it is possible to model both journeys with and without reference to a <trainPart> within a roster, as well as services without change of location (without reference to a <trainPart>). These 3 basic types are distinguished by the attribute mission. The following table presents the semantic constraints: (not included here)
<TT:blockPart> TT:004 2019-07-20 2019-07-18 vehicleRef and formationRef shall not be used within the same blockPart, since a blockPart is either one for a certain vehicle or one for a whole formation.
<TT:rostering> TT:005 2019-05-22 2019-06-25 vehicleRef and formationRef are to be used exceptional since the circulation plan is either one for a certain vehicle or one for a whole formation.
<TT:stopDescription> TT:006 2018-09-03 2019-06-20 Constraints between the attributes <ocpTT>.ocpType, <stopDescription>.guaranteedPass, .commercial, .onOff, .stopOnRequest and .operationalStopOrdered
<TT:stopDescription> (Stop on request / More than one stop type per OCP) TT:007 2019-06-19 discarded 2020-04-23
<TT:trackInfo> TT:008 2018-08-21 2019-06-20 The representation of differentiated track usage must not result in differences in arrival and departure times. In these cases, a separate <trainPart> / <train> with different arrival and departure times must be created.
<TT:trackInfo> TT:009 2018-08-21 2019-06-20 The operating days days of the <operatingPeriodRef>s of the individual <trackInfo> entries must be disjoint and must not contain more traffic days than the parent <trainPart>. If fewer traffic days are provided in the <trackInfo> entries than the parent <trainPart> contains, the information (e.g. attribute trackInfo) of the parent <ocpTT> must be evaluated for these operating days.
<TT:times> (Correct encoding of run time supplements) TT:010 2019-06-19 2020-10-15 @scope='earliest' and 'latest' are not intended to encode supplement times, as this is redundant to <ocpTT>.<sectionTT>.<runTimes>@operationalReserve, @additionalReserve, @minimalTime.
<TT:times> TT:011 2019-06-19 discarded
<TT:times> TT:012 2019-06-19 2022-06-02 When @scope='actual' is used, then the operating period and/or timetable period specified at the trainpart level shall refer to only one operating day. Like this the operating day to which the actual times refer is defined.
<TT:times> TT:013 2019-06-19 discarded
<TT:times> (Arrival times for passing OCP's) TT:014 2019-06-19 2022-06-02 @arrival is not to be specified if the attribute ocpType of the parent <ocpTT> has the value pass - use departure for run-through (passing) times; This is in line with the definition of @arrival as the moment at which the train ends its movement and gets to a halt at the parent <ocpTT>.
<TT:times> (Arrival time at first OCP) TT:015 2019-06-19 2022-06-02 At the first <ocpTT> of a <trainPart> that is not the first one of the <trainPartSequence>, the attribute @arrival is optional. If it is set anyway, then, for consistency reasons, the value of @arrival of the regarding <ocpTT> must be identical for both this <trainPart> and the preceding one.
<TT:times> (Departure time at last OCP) TT:016 2020-10-09 2022-06-02 At the last <ocpTT> of a <trainPart> that is not the last one of the <trainPartSequence>, the attribute @departure is optional. If it is set anyway, then, for consistency reasons, the value of @departure of the regarding <ocpTT> must be identical for both this <trainPart> and the subsequent one.
<TT:connection> TT:017 2022-12-15 2022-12-15 If the trainPartRef attribute is given, then there must also be a trainRef attribute, and the trainPartRef attribute must point to a train part of the train referenced by the trainRef attribute.
<IS:speedChange> IS:001 2019-04-11 discarded Always define trainRelation
<IS:trackEnd> IS:002 2019-06-17
<IS:trackBegin> IS:003 2019-06-17
<IS:track> IS:004 2019-06-17 Single track railway lines shall have main driving direction @mainDir="none" if they are used in both directions
<IS:ocp> IS:005 2019-06-19 2022-07-14 An <ocp> that refers to a parent <ocp> via an @parentOcpRef overwrites the attributes and elements of the parent <ocp> if explicitely defined. If an element is specified on an <ocp> that uses a @parentOcpRef any information provided with that element on a higher layer of the <ocp>-tree is overwritten. There is no merging of element-information from different levels. The same applies for attributes of <ocp>.
<IS:mileageChange> IS:006 2019-06-19
  • Define attributes @absPosIn and @absPos for "real" mileage changes
  • Define attribute @absPosIn alone in case of an ending mileage
  • Define attribute @absPos alone in case of a starting mileage
  • For starting mileages and "real" mileage changes, the @absDir has to be fiven to define the ongoing orientation of the mileage
<IS:propOperational> IS:007 2020-02-25 discarded
<IS:uptime> IS:008 2020-02-28 An <ocp> with <propOperational>@operationalType=blockSignal shall not have

@mode=manned (as a manned blockSignal shall be modelled in railML® 2.x as a blockPost).

<IS:uptime> IS:009 2020-02-28 An <ocp> with attribute <propOperational>@operationalType=stoppingPoint shall not have @mode=manned (as a stoppingPoint has no operational usage and therefore no operational staff by the IM).
<IS:uptime> IS:010 2020-02-28 An enumeration of several time periods by @from and @until for one <ocp> shall not overlap so that for every time there shall be a unique status of <uptime>.
<IS:speedChange> IS:011 2022-03-14 (to be def. more accurately) 2021-11-10 (40th conference slide 11)
  • Every <track> has to have at least one <speedChange> at the track begin with parameters @pos="0" and @dir="up".
  • Every <track> has to have at least one <speedChange> at the track end with parameters @pos="{value equal to trackEnd@pos}" and @dir="down".
<IS:speedProfile> IS:012 2022-03-14 @basicSpeedProfile is always linked with @influence=increasing
<IS:speedProfile> IS:013 2022-03-14
  • @influence=increasing: The <speedProfile> increases the permitted speed. If multiple "increasing" speed profiles are applicable, select the one with the highest @vMax value.
  • @influence=decreasing: The <speedProfile> decreases the permitted speed. If multiple "decreasing" speed profiles are applicable, select the one with the lowest @vMax value. If this value is lower than the speed of an "increasing" speed profile, it overrides that speed.
<IS:tunnel> IS:014 2022-03-14 Define the tunnel resistance factor @resistanceFactorPassenger resp. @resistanceFactorFreight only if @kind and @crossSection are not known.
<IS:ocp> IS:015 2022-07-14 2022-08-11 When specifying @parentOcpRef for an <ocp> circles are not allowed. That means that when following the chain of @parentOcpRef no <ocp> shall be visited twice.
<IS:axleWeightChange> <clearanceGaugeChange> <electrificationChange> <gaugeChange> <ownerChange> <gradientChange> <powerTransmissionChange> <radiusChange> IS:016 2021-11-10 2021-11-10 must not have @dir attribute according to Report from the Infrastructure developers in railML 3.2 and 2.5 (link to the railML® website) slide 9 and #357
<railml> <infrastructure> IS:017 2024-03-25 2021-03-25 either <infrastructure> or <railml> must have @version attribute
<metadata> @name IS:018 2024-03-25 2021-03-25 either <metadata> must have <dc:language> child or every @name attribute accompanied by @xml:lang
<IS:gradientChange> IS:019 2024-03-25 2021-03-25 there can be no two <gradientChange> belonging to the same track with the same @pos attribute
Retrieved from "https://wiki2.railml.org/index.php?title=Template:Table/Dev:Semantic_Constraints&oldid=15590"