Template:Table/Dev:Semantic Constraints
Element | ID | Proposal date | Date of acception | Date of deprecation | Description |
---|---|---|---|---|---|
<TT:operationalTrainSectionPart> | TT:001 | 2022-09-15 | 2022-10-13 | There is always only a single successor and predecessor for an <operationalTrainSectionPart> in the chain of <operationalTrainSectionPart>s that are linked via the attribute @next. | |
<TT:operationalTrainVariant> | TT:002 | 2023-01-12 | 2023-04-06 | When calculating which <operationalTrainVariant> of an <operationalTrain> is valid on a particular day always a maximum of one active <operationalTrainVariant> shall be the result. If the result is more than one <operationalTrainVariant>, all except one shall be marked as <isCancelled> or <isOnRequest>. | |
<TT:commercialTrainVariant> | TT:003 | 2023-01-12 | 2023-04-06 | When calculating which <commercialTrainVariant> of an <commercialTrain> is valid on a particular day always a maximum of one active <commercialTrainVariant> shall be the result. If the result is more than one <commercialTrainVariant>, all except one shall be marked as <isCancelled> or <isOnRequest>. | |
<TT:operationalTrainSection> | TT:004 | 2022-01-12 | 2023-03-09 | The itinerary sections of an <operationalTrainVariant>, defined by the <operationalTrainSection>s and their respective <range>s, that are not <isCancelled> and not marked as <isOnRequest>, must be pairwise disjoint, except for their respective first and last <baseItineraryPoint>s. | |
<TT:operationalTrainSection> | TT:005 | 2022-01-12 | 2023-03-09 | The first(last) <baseItineraryPoint> of each <operationalTrainSection> within an <operationalTrainVariant> must either be the referenced <itinerary>'s first(last) <baseItineraryPoint>, or coincide with another section's last(first) <baseItineraryPoint>. | |
<TT:commercialTrainSection> | TT:006 | 2022-01-12 | 2023-03-09 | The itinerary sections of an <commercialTrainVariant>, defined by the <commercialTrainSection>s and their respective <range>s, that are not <isCancelled> and not marked as <isOnRequest>, must be pairwise disjoint, except for their respective first and last <baseItineraryPoint>s. | |
<TT:commercialTrainSection> | TT:007 | 2022-01-12 | 2023-03-09 | The first(last) <baseItineraryPoint> of each <commercialTrainSection> within an <commercialTrainVariant> must either be the referenced <itinerary>'s first(last) <baseItineraryPoint>, or coincide with another section's last(first) <baseItineraryPoint>. | |
<RTM:isValid>, <CO:validityTime:period> | IS:001 | 2024-01-15 |
Starting time stamp (e.g. "from") shall be lower or equal any ending time stamp (e.g. "to") if both are given. Must not overlap with other validity periods. | ||
<IS:trainProtectionElement> | IS:002 | 2021-02-26 |
<trainProtectionElement> shall only be used for national and/or legacy train protection systems. ETCS-based systems must not be modeled using <trainProtectionElement>. | ||
<IS:levelCrossingIS> | IS:003 | 2023-10-23 |
<levelCrossingIS> should not have a <crossesElement> child of type railway. This case should be represented either by a <crossing> in case of a simple crossing, or by a <switchIS> of type doubleSwitchCrossing or singleSwitchCrossing. | ||
<IS:underCrossing>, <IS:overCrossing> | IS:004 | 2023-10-23 |
should only have a <crossesElement> child of type railway when your railway line is crossing itself (not on the same level!). | ||
<IS:signalConstruction> | IS:005 | 2024-01-22 |
@height and @positionAtTrack should not be used with @type=virtual. | ||
<IS:line> | IS:006 | 2024-01-29 |
each line with own mileage should always be associated with its own <linearPositioningSystem>, i.e. Advanced example of railML has three lines with their own mileages, thus should have thee <linearPositioningSystem>s. |