Template:Table/Dev:Semantic Constraints
(Redirected from Dev:Semantic Constraints/table2)
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: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. See also https://wiki2.railml.org/wiki/Dev:Defining_temporal_availability_of_infrastructure_elements_and_speed_profiles | |
| <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. See also https://wiki2.railml.org/wiki/Dev:Defining_temporal_availability_of_infrastructure_elements_and_speed_profiles | |
| <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. | |
| 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: (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: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:001 | 2019-04-11 | discarded | |||
| <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 |
| ||
| 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) |
| |
| <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. | |
| <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 |