| Re: railML 2.3 infrastructure extension for capacity planning and network statement usecases [message #1508 is a reply to message #1463] |
Fri, 24 February 2017 14:45  |
Torben Brand
Messages: 158
Registered: March 2016
|
Senior Member |
|
|
>The proposals are based on railML v2.3. As stated earlier there will be
>no railML v2.4 with just infrastructure scheme changes. However, if
>there is a decision to go for a railML v2.4 (pushed by requirements of
>the timetable schema), how do you want to handle the proposed changes?
>Do you want to see them implemented in railML v2.4 or better in v3?
I suggest to implement the suggested element extensions in both railML 2.4 (if developed) and in railML3. This as they must be part of railML3 as they are part of the capacity planning use case. Both implementations have benefits and disadvantages. railML 2 is available, tested, extensions are relatively simple and the model is relative simple to implement. RailML3 has more functionality, but the model is not developed and tested fully and is more complex. Thus I recommend a parallel approach.
Some of the elements suggested her border towards the interlocking schema. They all derive from the capacity planning use case. And thus they describe, in our perspective, more the interlocking's operational functionality than a technical description. We need to solve as much of this use case as possible as soon as possible. Thus we suggest using the proposed extensions in railML2 infrastructure.
|
|
|
|
Members
Search
Help
Login
Home
