Remodel organizationalUnits
Description
The modelling of organizationalUnits in railML 3.1 was copied as is from railML 2.x. The recent discussion about enhancements for railML 2.5 has highlighted that the syntax is not ideal. A typical railML 3 approach would be more flexible and at the same time remove the need to define the same organisation multiple times.
Background
Since railML 2.2 organizationalUnits of different types (, , , , , , and ) can be defined and referenced from TT and RS. The references are type specific, so a vehicleOperatorRef must point to a vehicleOperator element, even when a railwayUndertaking operates its vehicles itself. In consequence, the same organization must often be defined multiple times, e.g. both as a railwayUndertaking and as a vehicleOperator, without any standard mecanism to tell that the two are the same.
Links
- Forum discussion:
- Torben Brand on refining organizationalUnits in railML 2.5, 10.02.2020, https://www.railml.org/forum/index.php?t=msg&th=706&start=0&
- When introducing organizational units in 2013, https://www.railml.org/forum/index.php?t=msg&goto=1102
- Trac tickets:
- #435 add vehicleOwner in railML 2.5
- #178 original introduction of organizationalUnits in railML 2.2
- Wiki documentation:
- http://wiki3.railml.org/index.php?title=CO:organizationalUnits
Proposed solution
Create new general child element organizationalUnit, with attributes or child elements for each of the organizationalUnit types (e.g. isInfrastructureManager).
Deprecate and then remove existing child elements of organizationalUnits.