Template:List/Dev:SemanticConstraints
Jump to navigation
Jump to search
|
| ID | Text | Status | Proposed | Approved | Deprecated | Forum | Instances
|
|---|---|---|---|---|---|---|---|
| CO:001 |
@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:001 |
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 within the same enclosing element. |
proposed |
2024-01-15 |
Not yet approved |
FIXME Forum missing |
| |
| IS:005 |
@height and @positionAtTrack should not be used with @type=virtual. |
approved |
2021-02-26 |
2025-02-03 |
Please, discuss this semantic constraint in the railML® forum topic "Construction of virtual signals (link to the railML® website)". |
| |
| IS:007 |
When providing the value 'true' to the attribute @isOpenEnd of <border> the attribute @type shall always be set to area. |
approved |
2024-06-25 |
2025-05-19 |
https://www.railml.org/forum/index.php?t=msg&th=955&start=0& |
| |
| IS:008 |
When aggregating net elements each <netElement> of a lower level of aggregation shall only directly belong to a single <netElement> of a higher level of aggregation. |
approved |
2021-02-26 |
2025-05-19 |
https://www.railml.org/forum/index.php?t=msg&th=948&start=0& |
| |
| IS:009 |
Linear (geometric) coordinates (explicit or implicit, e.g. calculated as a sum of the coordinate of beginning and the length of the net element) of the same place represented at different levels of aggregation should have the same value. In the figure below (linear) coordinate the coordinate of e.g. end of ne1 should be same as one of ne1.2. |
proposed |
2021-02-26 |
Not yet approved |
Please, discuss this semantic constraint in the railML® forum topic "Restricting aggregation of RTM (link to the railML® website)". |
| |
| IS:010 |
Difference of linear coordinates if the beginning and end of net elements, represented by intrinsic coordinates 0 and 1 correspondingly, should equal the the @length of net element if all are present in the data. |
proposed |
2021-02-26 |
Not yet approved |
| ||
| IS:011 |
Aggregation must not happen within the same <level> of aggregation. No <netElement> of a certain <level> of aggregation shall be part of another <netElement> on the same <level> of aggregation. |
approved |
2024-02-29 |
2025-05-19 |
https://www.railml.org/forum/index.php?t=msg&th=948&start=0& |
| |
| IS:012 |
@pos should have only positive values because its a distance, thus -1 is not a valid value – Compare #567 |
proposed |
2024-03-04 |
Not yet approved |
| ||
| IS:014 |
@startMeasure and @endMeasure are start and end values of a railway <IS:line> associated with <RTM:linearPositioningSystem> not max and min values of a current file with e.g. line section |
proposed |
2024-04-08 |
Not yet approved |
Please, discuss this semantic constraint in the railML® forum topic Restricting IS:line and RTM:linearPositioningSystem (link to the railML® website)". |
| |
| IS:015 |
There must be no "inverse" net relations in the topology, i.e. if "nr1 elemeneA ne1", "nr1 elementB ne2" and "nr2 elemeneA ne2", "nr2 elementB ne1" then topology is not valid. See invalid code below – Compare |
proposed |
2021-04-22 |
Not yet approved |
| ||
| IS:017 |
Users can refer to the train protection system using the attribute @trainProtectionSystem that shall link to the codelist (link to the railML® website) TrainProtectionSystems.xml, section trainProtectionSystemsAtTrack. Only if this list does not contain the specific train protection system to be modelled, it shall be described in its functionality using attributes @medium and @monitoring. |
proposed |
2025-04-29 |
Not yet approved |
Please, discuss this semantic constraint in the railML® forum topic Consistent use of <train-Protection-System> (link to the railML® website)". |
| |
| IS:018 |
Any functional infrastructure element that belongs to an <operationalPoint> may be listed as its equipment. This may be done by adding it to a specific container, such as <ownsPlatform>, <ownsTrack> and <ownsSignal> or it may be added to the generic container <ownsInfrastructureElement>. Any such added infrastructure element must be added to the most specific container available. No element shall be part of two such containers. If no specific container for the functional infrastructure element exists, it shall be listed in the generic container. Example: a <signalIS> must not be added to <ownsInfrastructureElement>. It shall be added to <ownsSignal>. As there is no container for levelCrossings a <levelCrossingIS> belonging to an <operationalPoint> shall be added to <ownsInfrastructureElement>. |
proposed |
2024-08-26 |
Not yet approved |
Please, discuss this semantic constraint in the railML® forum topic "Usage of <owns-Platform> vs <owns-Infrastructure-Element> (link to the railML® website)". |
| |
| IS:019 |
When calculating which <infrastructureState> of an <infrastructure> is valid on a particular time always a maximum of one active <infrastructureState> shall be the result. |
proposed |
2024-09-03 |
Not yet approved |
Please, discuss this semantic constraint in the railML® forum topic New semantic constraint to ensure unambiguous infrastructure states (link to the railML® website)". |
| |
| IS:021 |
The element <baliseGroup> shall always use the railML® option <spotLocation> when defining the balise group location on the topology. |
approved |
2025-04-30 |
2025-05-19 |
https://www.railml.org/forum/index.php?t=msg&th=980&start=0& |
| |
| IS:022 |
The element <balise> shall always use the railML® option <spotLocation> when defining the balise location on the topology. |
approved |
2025-04-30 |
2025-05-19 |
https://www.railml.org/forum/index.php?t=msg&th=980&start=0& |
| |
| IS:023 |
<linearCoordinate>/@measure , <linearCoordinateBegin>/@measure , <linearCoordinateEnd>/@measure must be ≥ @startMeasure and ≤ @endMeasure of the corresponding <linearPositioningSystem>. |
approved |
2025-02-17 |
2025-09-08 |
Making consistent linearPositioningSystem and linear coordinates (link to the railML® website) |
| |
| IS:024 |
When specifying an <intrinsicCoordinate> with 0 < @intrinsicCoord < 1, it needs to be ensured that a given <linearCoordinate> is aligned with the referenced <linearPositioningSystem>. |
approved |
2025-04-02 |
2025-10-13 |
https://www.railml.org/forum/index.php?t=msg&th=1045&start=0& |
| |
| IS:025 |
Each <netElement> must belong to exactly one <level>. |
proposed |
2025-02-27 |
Not yet approved |
https://www.railml.org/forum/index.php?t=msg&th=1032&start=0& |
| |
| IS:026 |
Each <netRelation> must belong to exactly one <level>. |
proposed |
2025-02-27 |
Not yet approved |
https://www.railml.org/forum/index.php?t=msg&th=1032&start=0& |
| |
| IS:027 |
If <switchToLevel>/@levelType="ETCS", then only the following values are accepted: <switchToLevel>/@levelValue="0", <switchToLevel>/@levelValue="1", <switchToLevel>/@levelValue="2", <switchToLevel>/@levelValue="3". |
proposed |
2025-10-08 |
Not yet approved |
https://www.railml.org/forum/index.php?t=msg&th=1095&start=0& |
| |
| IS:028 |
If <switchToLevel>/@levelType="NTC", then the <switchToLevel>/@levelValue shall conform to the NID_NTC-values specified in the ERA document Assignment of values to ETCS variables (external link). |
proposed |
2025-10-08 |
Not yet approved |
https://www.railml.org/forum/index.php?t=msg&th=1095&start=0& |
| |
| TT:001 |
The next attribute shall reference an <operationalTrainSectionPart> that is not referenced by any other next-reference. In other words: Within the chain of <operationalTrainSectionPart>s linked by the attribute next, there can be no element that has more than one predecessor. The @next reference must establish a one to one relationship between two <operationalTrainSectionPart>s. |
approved |
2022-09-15 |
2025-09-08 |
https://www.railml.org/forum/index.php?t=msg&th=1078&start=0& |
| |
| TT:002 |
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>. |
approved |
2023-01-12 |
2025-09-08 |
https://www.railml.org/forum/index.php?t=msg&th=1079&start=0& |
| |
| TT:003 |
When calculating which <commercialTrainVariant> of a <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>. |
approved |
2023-01-12 |
2025-09-08 |
https://www.railml.org/forum/index.php?t=msg&th=1080&start=0& |
| |
| TT:004 |
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. |
approved |
2023-01-12 |
2023-03-09 |
Please, discuss this semantic constraint in the railML® forum topic Semantic Constraints for Train Section (link to the railML® website). |
| |
| TT:005 |
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>. |
approved |
2023-01-12 |
2023-03-09 |
Please, discuss this semantic constraint in the railML® forum topic Semantic Constraints for Train Section (link to the railML® website)". |
| |
| TT:006 |
The itinerary sections of a <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. |
approved |
2023-01-12 |
2023-03-09 |
Please, discuss this semantic constraint in the railML® forum topic Semantic Constraints for Train Section (link to the railML® website)". |
| |
| TT:007 |
The first(last) <baseItineraryPoint> of each <commercialTrainSection> within a <commercialTrainVariant> must either be the referenced <itinerary>'s first(last) <baseItineraryPoint>, or coincide with another section's last(first) <baseItineraryPoint>. |
approved |
2023-01-12 |
2023-03-09 |
Please, discuss this semantic constraint in the railML® forum topic Semantic Constraints for Train Section (link to the railML® website)". |
| |
| TT:008 |
No two attributes //<times>/@scope of the same enclosing <baseItineraryPoint> element shall have the same value. |
approved |
2024-11-21 |
2025-04-07 |
Please, discuss this semantic constraint in the railML® forum topic "Proposed semantic constraint for <times> (link to the railML® website)". |
|