Template:Table/Dev:SemanticConstraints

Return to article

Element	ID	Proposal date	Date of acceptance	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>	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: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>	TT:024	2018-11-12	2019-03-21		Any starting time (as it may result e.g. from a combination of @beginDay and @begin) shall be lower or equal any ending time (as it may result e.g. from a combination of @endDay and @end) 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 from @startDateTime or a combination of @operatingPeriod and @startTime) shall be lower or equal any ending time stamp (as it may result from @endDateTime or a combination of @endDayOffset and @endTime) if both are given. Must not overlap with other <state> validity periods of the same enclosing <states> collection. See also 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 from @startDateTime or a combination of @operatingPeriod and @startTime) shall be lower or equal any ending time stamp (as it may result from @endDateTime or a combination of @endDayOffset and @endTime) if both are given. Must not overlap with other <state (with length)> validity periods of the same enclosing <states (with length)> collection. See also 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: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: see table
<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. The only exception to this rule is if the formation consists of only one vehicle that is also specified via vehicleRef
<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. The only exception to this rule is if the formation consists of only one vehicle that is also specified via vehicleRef
<TT:stopDescription>	TT:006	2018-09-03	2019-06-20		Constraints between the attributes <ocpTT>.ocpType, <stopDescription>.guaranteedPass, .commercial, .onOff, .stopOnRequest and .operationalStopOrdered
<TT:trackInfo>	TT:009	2018-08-21	2019-06-20		The operating 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>	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		Arrival times at the common operating point of two consecutive <trainPart>'s of the same <train> must not contradict each other. This can be implemented either - by only the preceding <trainPart> having arrival times while the succeeding <trainPart> does not at this operating point or - by both <trainPart>'s having identical arrival times. These rules apply to the arrival times in each of the specified scope's.
<TT:times> (Departure time at last OCP)	TT:016	2020-10-09	2022-06-02		Departure times at the common operating point of two consecutive <trainPart>'s of the same <train> must not contradict each other. This can be implemented either - by the preceding <trainPart> having no departure times and only the succeeding <trainPart> specifying them at this operating point or - by both <trainPart>'s having identical departure times. These rules apply to the departure times in each of the specified scope's.
<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:trackEnd>	IS:002	2019-06-17			The value of @pos in <trackBegin> is always the lowest value of all specified <trackElements> and <ocsElements>. It is always lower (or equal if length = 0) than the value of @pos of <trackEnd>. The value of @pos in <trackEnd> is always the highest value of all specified <trackElements> and <ocsElements>. It is always higher (or equal if length = 0) than the value of @pos of <trackBegin>. Subtracting the value of @pos in <trackBegin> from the value of @pos in <trackEnd> will result in the length of the enclosing <track>. If two <track>s are connected, the @absPos values of the connected <trackBegin> and <trackEnd> must be identical if both are provided and no <mileageChange> is defined at this point and both <track>s belong to the same mileage system.
<IS:trackBegin>	IS:003	2019-06-17			The value of @pos in <trackBegin> is always the lowest value of all specified <trackElements> and <ocsElements>. It is always lower (or equal if length = 0) than the value of @pos of <trackEnd>. The value of @pos in <trackEnd> is always the highest value of all specified <trackElements> and <ocsElements>. It is always higher (or equal if length = 0) than the value of @pos of <trackBegin>. Subtracting the value of @pos in <trackBegin> from the value of @pos in <trackEnd> will result in the length of the enclosing <track>. If two <track>s are connected, the @absPos values of the connected <trackBegin> and <trackEnd> must be identical if both are provided and no <mileageChange> is defined at this point and both <track>s belong to the same mileage system.
<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 given to define the ongoing orientation of the mileage
<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: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.
<TT:times>	TT:020	2024-11-21	2025-04-07		No two attributes //<times>/@scope of the same enclosing <ocpTT> element shall have the same value.
<TT:specialService>	TT:021	2025-02-13	2025-04-07		Within the same enclosing element, a date must not be contained in more than one <specialService> element.
<TT:specialService>	TT:022	2025-02-13	2025-04-07		The values of @singleDate, @startDate and @endDate of <specialService> must not be outside of the time period defined in the related <operatingPeriod>.
<TT:brakeUsage>	TT:023	2025-03-13	2025-04-07		The attribute @airBrakeApplicationPosition if specified shall have the value N/A if the attribute @brakeType indicates a different type of brake than a pneumatic brake system (value compressedAir or vacuum).