Template:Table/Dev:Semantic Constraints

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: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:operatingPeriodRef>	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:operatingPeriod>	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:operatingDay>	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:circulation>	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:blockPart>	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.
<RS:designator> (introduced with version 2.5)	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.
<RS:operator>	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.
<RS:owner> (introduced with version 2.5)	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.
<RS:state>	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.
<IS:state>	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.
<IS:state (with length)>	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.
<IS:designator>	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.
<CO:designator> (introduced with version 2.5)	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.
<CO:phase> (introduced with version 2.5)	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: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			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: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