| [railML 3.4 beta 4] topology netelements no longer have validity [message #4044] |
Tue, 16 June 2026 21:15  |
Mathias Vanden Auweele
Messages: 143
Registered: February 2025
Location: Brussels
|
Senior Member |
|
|
Hello,
I'm trying to make sense of the changes in the rtm4railml3 schema. It seems RTM_NetworkResource now still extends from RTM_NamedResource but it no longer adds the element:
<xs:element name="isValid" type="rail3:RTM_Validity" minOccurs="0" maxOccurs="unbounded"/>
I'm guessing that this is due to RTM_NetEntity receiving the elementState element:
<xs:complexType name="RTM_NetEntity">
<xs:annotation>
<xs:documentation>Objects like infrastructure assets can be located on the network as NetEntities</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="rail3:RTM_NamedResource">
<xs:sequence>
<xs:element name="elementState" type="rail3:SubSchemaElementState" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
However, this means that it's no longer possible to assign validity periods to other elements that are inheriting from RTM_NamedResource, such as RTM_NetElement, RTM_Network, RTM_Relation, ...
This is a major change! I'm guessing that this was an accident and perhaps the intention was to put the new elementState element on the RTM_NamedResource where previously the validity was?
Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
[Updated on: Tue, 16 June 2026 21:16] Report message to a moderator |
|
|
|
|
|
| Re: [railML 3.4 beta 4] topology netelements no longer have validity [message #4046 is a reply to message #4045] |
Tue, 16 June 2026 23:05  |
Mathias Vanden Auweele
Messages: 143
Registered: February 2025
Location: Brussels
|
Senior Member |
|
|
I'm reading the gitlab ticket https://development.railml.org/railml/version3/-/issues/720
(so I'm concluding that the major change is not an accident)
In the gitlab ticket, the question is phrased whether topology elements such as netelement and netrelations need a validity. Of course they do. To begin with, a netrelation can change over time. A switch that implements a relation could be decomissioned. Netelements also come and go. The applications that manage topology do not want to show netelements in selection lists or vizualisations when those netelements are no longer valid. Else it would be a mess.
In infrastructure life cycle data management, the core of the railway problem is managing topology. At the very beginning of network extensions, the topology is drawn. It will never be with the exact words as topology, netelement and netrelations. But they will start drawing schematics and those schematics change a couple of times. They might use words such as track and switch but the exact implementation (going through concept, design, planned, as build) is decided during infrastructure projects, not before.
Yes there can be a problem when topology validity periods don't correspond to netentity location validities. We can say the same about operational points that own deprecated tracks or signals. Or in general any kind of element with type="rail3:tElementWithIDref"
If you still doubt the above explanation, then consider validity periods for topology resources as their data validity periods. This as opposed to real-world or operational validity periods. Although I only bring this up as this is guaranteed to be possible, whatever your mindset is, and associated with topology resources. But I still believe a real-world and/or operational validity is applicable to and must be defined for topology resources.
Mathias Vanden Auweele
Railway data freelancer
https://matdata.eu
Brussels, Belgium
|
|
|
|
| Re: [railML 3.4 beta 4] topology netelements no longer have validity [message #4070 is a reply to message #4046] |
Thu, 02 July 2026 09:55 |
Milan Wölke
Messages: 230
Registered: April 2007
|
Senior Member |
|
|
Hi Mathias,
we discussed your remarks in the last modelling telco. We wanted to remove the isValid primarily from the NetEntities because of the redundancy with the state representation. After considering your input we decided to keep the isValid at the NetRelations and the NetElements. After all they do not have an elementState. However we still think that for NetEntities the state approach is better suited to describe the operational realities.
Best regards, Milan
Milan Hoffmann – Timetable schema coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
Members
Search
Help
Login
Home
