Template:List/Dev:SemanticConstraints

From railML 2 Wiki
Jump to navigation Jump to search

Return to article

🗒️ Start here to learn how to enter semantic constraints into this wiki.  
ID Text Status Proposed Approved Deprecated Forum Instances


CO:001
 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.
 approved
 2018-11-12
 2019-03-21
FIXME Forum missing


CO:002
 Relation of starting and ending timestamps of a time period
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.
 approved
 2018-11-12
 2019-03-21
FIXME Forum missing


CO:003
 @version shall correspond to the specified namespace of the <railml> element.
 approved
 2025-10-13
 2025-10-13
https://www.railml.org/forum/index.php?t=msg&th=1101


IS:002
 proposed
 2019-06-17
 Not yet approved
FIXME Forum missing


IS:003
 proposed
 2019-06-17
 Not yet approved
FIXME Forum missing


IS:006
  • 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

 proposed
 2019-06-19
 Not yet approved
FIXME Forum missing


IS:008
 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).
 proposed
 2020-02-20
 Not yet approved
FIXME Forum missing


IS:009
 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).
 proposed
 2020-02-28
 Not yet approved
FIXME Forum missing


IS:010
 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>.
 proposed
 2020-02-28
 Not yet approved
FIXME Forum missing


IS:012
 If a <speedProfile> is marked with @basicSpeedProfile=true the attribute @influence shall have the value increasing.
 proposed
 2022-03-14
 Not yet approved
#424


IS:013
  • @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.

 proposed
 2022-03-14
 Not yet approved
#424


IS:014
 Define the tunnel resistance factor @resistanceFactorPassenger resp. @resistanceFactorFreight only if @kind and @crossSection are not known.
 proposed
 2022-03-14
 Not yet approved
FIXME Forum missing


IS:015
 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.
 approved
 2022-07-14
 2022-08-11
Approved during the timetable developer group meeting on 2022-08-11


IS:020
 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
 approved
 2018-11-12
 2019-03-21
FIXME Forum missing


IS:021
 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
 approved
 2018-11-12
 2019-03-21
FIXME Forum missing


RS:002
 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>.
 approved
 2018-11-12
 2019-03-21
FIXME Forum missing


RS:003
 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>.
 approved
 2018-11-12
 2019-03-21
FIXME Forum missing


RS:004
 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 <vehicle>/<states>.
 approved
 2018-11-12
 2019-03-21
FIXME Forum missing


TT:001
 Starting and ending timestamps within <timetablePeriod>
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:001
 approved
 2018-11-12
 2019-03-21
FIXME Forum missing


TT:002
 The attribute sequence is shall be increasing according to the train path.
Das Attribut sequence muss ansteigend entsprechend dem Zuglauf sein.
 approved
 2018-10-25
 2019-06-20
FIXME Forum missing


TT:003
 Allowed attributes in <blockPart> for services and trips with or without references to <trainPart>
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:

Mit Hilfe eines <blockPart> können innerhalb eines Umlaufplans sowohl Fahrten mit und ohne Referenz auf einen <trainPart> abgebildet werden, als auch Dienste ohne Ortsveränderung (ohne Referenz auf einen <trainPart>). Unterschieden werden diese 3 Grundtypen anhand des Attributs mission. In der folgenden folgende Tabelle werden die semantischen Abhängigkeiten gegenüber gestellt:

attributes of <blockPart>
mission trainPartRef startOcpRef / endOcpRef begin / end, beginDay / endDay runLength
trip with reference to a <trainPart> timetable mandatory redundant to referenced <trainPart>, must be empty or without contradiction to referenced <trainPart>
trip without reference to a <trainPart> fullRun, emptyRun shall not be used mandatory mandatory optional
service all other values shall not be used mandatory, startOcpRef = endOcpRef mandatory optional


approved
 2019-06-13
 2019-07-18
FIXME Forum missing


TT:004
 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.
Es ist nur entweder vehicleRef oder formationRef anzugeben (nicht jedoch beide gleichzeitig), da es sich entweder um einen Blockpart eines Einzelfahrzeugs oder einer Fahrzeuggruppe handelt. Die einzige zulässige Ausnahme stellt der Fall dar, dass die angegebene Formation ausschließlich aus dem über vehicleRef angegbenen Fahrzeug besteht.
 approved
 2019-06-20
 2019-07-18
FIXME Forum missing


TT:005
 Usage of @formationRef and @vehicleRef in <blockPart> and <rostering>
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
Es ist nur entweder vehicleRef oder formationRef anzugeben (nicht jedoch beide gleichzeitig), da es sich entweder um einen Umlauf eines Einzelfahrzeugs oder einer Fahrzeuggruppe handelt. Die einzige zulässige Ausnahme stellt der Fall dar, dass die angegebene Formation ausschließlich aus dem über vehicleRef angegbenen Fahrzeug besteht.
 approved
 2019-05-22
 2019-06-25
FIXME Forum missing


TT:006
 Allowed attributes in <stopDescription> for stops and passes
The following table summarises the semantical constraints between the attributes <ocpTT>.ocpType, <stopDescription>.guaranteedPass, .commercial, .onOff, .stopOnRequest and .operationalStopOrdered:

RailML 2 stopDescription constraints.png

  • Green cells are assumed to be default values.
  • ocpType='begin','end' are deprecated from railML® 2.2.
  • If no <stopDescription> is given, it is either a non-guaranteed pass (1.2) or a stop with undefined properties, depending on the attribute ocpType.
  • The term "commercial" of the attribute in railML® traditionally refers to the contractual relationship between RU and end-customer, not to the contractual relationship between IM and RU.
  • The term "ordered" in the attribute operationalStopOrdered refers to the contractual relationship between IM and RU.

 approved
 2018-09-03
 2019-06-20
FIXME Forum missing


TT:008
 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.
Die Abbildung unterschiedlicher Gleisnutzungen darf keine Unterschiede in den Ankunfts- und Abfahrtszeiten zur Folge haben. In diesen Fällen muss ein separater <trainPart> / <train> mit abweichenden Ankunfts-/Abfahrtszeiten angelegt werden.
 approved
 2018-08-21
 2019-06-20
FIXME Forum missing


TT:009
 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.
Die Verkehrstage der <operatingPeriodRef>s der einzelnen <trackInfo>-Einträge müssen untereinander disjunkt sein und dürfen nicht mehr Verkehrstage als der übergeordnete <trainPart> enthalten. Werden durch die <trackInfo>-Einträge weniger Verkehrstage abgedeckt, als der übergeordnete <trainPart> aufweist, so sind für diese Verkehrstage die Angaben (z.B. Attribut trackInfo) der übergeordneten <ocpTT> zu verwenden.
 approved
 2018-08-21
 2019-06-20
FIXME Forum missing


TT:012
 <operatingPeriod> for <trainPart> with actual <times> data
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.
Wenn @scope= 'actual' verwendet wird, bezieht sich die operating period und/oder timetable period des train(part) auf nur einen einzelnen Betriebstag. Es muss so festgelegt werden, auf welchen Betriebstag sich die erfassten Ist-Zeiten beziehen.
 approved
 2019-06-19
 2022-06-02
FIXME Forum missing


TT:014
 No arrival <times> at passing <ocpTT>
@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>.
 approved
 2019-06-19
 2022-06-02
FIXME Forum missing


TT:015
 Consistency of arrival / departure <times> for consecutive <trainPart> elements
Arrival times at the common operating point of two consecutive <patternTrainPart>'s of the same <patternTrain> must not contradict each other. This can be implemented either
- by only the preceding <patternTrainPart> having arrival times while the succeeding <patternTrainPart> 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.

 approved
 2019-06-19
 2022-06-02
Please, discuss this semantic constraint in the railML® forum topics "Wording of semantic constraints TT:015 and TT:016 (link to the railML® website)" and "Wording of semantic constraints TT:015 and TT:016 (link to the railML® website)".


TT:016
 Departure times at the common operating point of two consecutive <patternTrainPart>'s of the same <patternTrain> must not contradict each other. This can be implemented either
- by the preceding <patternTrainPart> having no departure times and only the succeeding <patternTrainPart> specifying them at this operating point or
- by both <patternTrainPart>'s having identical departure times.


These rules apply to the departure times in each of the specified @scope's.

 approved
 2020-10-09
 2022-06-02
Please, discuss this semantic constraint in the railML® forum topics "Wording of semantic constraints TT:015 and TT:016 (link to the railML® website)" and "Wording of semantic constraints TT:015 and TT:016 (link to the railML® website)".


TT:017
 Usage of <trainRef> and <trainPartRef> attributes in <connection>
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.
 approved
 2022-12-15
 2022-12-15
Agreed at the TT-devellopers-conference on December 15th 2022


TT:019
 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>.
 approved
 2018-11-12
 2019-03-21
FIXME Forum missing


TT:020
 Usage of @scope attribute in <times>
No two attributes //<times>/@scope of the same enclosing <ocpTT> element shall have the same value.
 approved
 2025-04-07
 2024-12-19
https://www.railml.org/forum/index.php?t=msg&th=1013&start=0&


TT:021
 Within the same <operatingPeriod> element, a date must not be contained in more than one <specialService> element.
 approved
 2025-02-13
 2025-04-07
https://www.railml.org/forum/index.php?t=msg&th=1014&start=0&


TT:022
 The values of @singleDate, @startDate and @endDate of <specialService> must not be outside of the time period defined in the enclosing <operatingPeriod>.
 approved
 2025-02-13
 2025-04-07
https://www.railml.org/forum/index.php?t=msg&th=1014&start=0&


TT:023
 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).
 approved
 2025-03-13
 2025-04-07
https://www.railml.org/forum/index.php?t=msg&th=1031&start=0&


TT:024
 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.
 approved
 2018-11-12
 2019-03-21
FIXME Forum missing


Retrieved from "https://wiki2.railml.org/index.php?title=Template:List/Dev:SemanticConstraints&oldid=19069"