Template:Table/Dev:Semantic Constraints
Jump to navigation
Jump to search
| 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 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 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. | |
| 2018-10-25 | discarded | ||||
| <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 here (link to the railML® website) | |
| <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: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 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:001 | 2019-04-11 | discarded | |||
| <IS:trackEnd> | IS:002 | 2019-06-17 |
| ||
| <IS:trackBegin> | IS:003 | 2019-06-17 |
| ||
| <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 |
| ||
| 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 | 2020-10-12 (date of creation of ticket 425) | 2021-11-10 (40th conference slide 11) | 2024-10-02 (railML.org Governance Coord approved) |
|
| <IS:speedProfile> | IS:012 | 2022-03-14 | @basicSpeedProfile is always linked with @influence=increasing | ||
| <IS:speedProfile> | IS:013 | 2022-03-14 |
| ||
| <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 | No two attributes //<times>/@scope of the same enclosing stop/pass elements shall have the same value. |